E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Sudheer Babu
Date: Tue, Aug 08 2023 7:53PM
Subject: Query regarding equal access accessibility checker reported bug
No previous message | Next message →

Hello All,

We have recently got our application pages scanned with IBM equal access
accessibility checker. While the tool gave some very good findings, I
wanted to discuss about one issue which I felt was false positive and would
need your inputs if you have come across any.

This is the rule that failed - "HTML element with an assigned accesskey
attribute doesn't have an associated label.

Code Snippet:
<input tabindex="0" class="btn btn-primary" blockui="true"
data-id="btnNext" accesskey="n" id="ctI100btnNext" value="Next"
name="ctl00$ct100$cph Main$cphMain$btnN ext" type="submit">

From the above code snippet, the accesskey attribute along with the 'Value'
attribute provides both visual and accessible label for screen readers.

So, do we need to consider the issue reported by the tool as false positive
or if we have to correct this to the standard "Label for" ?

Thanks in advance!

Regards,
Sudhir.

From: glen walker
Date: Wed, Aug 09 2023 12:28AM
Subject: Re: Query regarding equal access accessibility checker reported bug
← Previous message | Next message →

IBM's accessibility checker marks it as an "info" warning, not a failure,
so it's not a WCAG failure. But I agree it's a false positive in the way
it's reporting it since the <input> does indeed have an accessible name
that comes from the value attribute.

The HTML spec for <input type="submit"> says:

"If the element has a value attribute, the button's label must be the value
of that attribute"

https://html.spec.whatwg.org/multipage/input.html#submit-button-state-(type=submit)

The button's label will be the accessible name.

Both WAVE and ARCToolkit report the accesskey as a warning and suggest you
not use it, but again, it's a warning and not a failure.
Axe doesn't say anything about it.

As a keyboard user myself, I love having an accesskey, but it's not very
discoverable (if at all). I generally have to inspect the code to see if
there's a field that I'm hoping has an access key, such as the search field
on wikipedia.org

From: Sudheer Babu
Date: Wed, Aug 09 2023 10:21AM
Subject: Re: Query regarding equal access accessibility checker reported bug
← Previous message | No next message

Thanks for confirming Glen!
This is extremely helpful.

On Wed, Aug 9, 2023 at 11:59 AM glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> IBM's accessibility checker marks it as an "info" warning, not a failure,
> so it's not a WCAG failure. But I agree it's a false positive in the way
> it's reporting it since the <input> does indeed have an accessible name
> that comes from the value attribute.
>
> The HTML spec for <input type="submit"> says:
>
> "If the element has a value attribute, the button's label must be the value
> of that attribute"
>
>
> https://html.spec.whatwg.org/multipage/input.html#submit-button-state-(type=submit)
>
> The button's label will be the accessible name.
>
> Both WAVE and ARCToolkit report the accesskey as a warning and suggest you
> not use it, but again, it's a warning and not a failure.
> Axe doesn't say anything about it.
>
> As a keyboard user myself, I love having an accesskey, but it's not very
> discoverable (if at all). I generally have to inspect the code to see if
> there's a field that I'm hoping has an access key, such as the search field
> on wikipedia.org
> > > > >