WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Relationship between WCAG and the ARIA in HTML specification

for

From: Birkir R. Gunnarsson
Date: Aug 7, 2023 1:42PM

I also wonder, if we keep going down this path, whether we still need
to report labels that are not connected to inputs under 4.1.2 or
1.3.1, if one or two screen reader browser combinations guess them
right.
Jaws has become pretty good at this for simple forms, NVDA less so,
but maybe that's an NVDA bug now.

It's the same thought process as 4.1.1 removal, if the user agents can
guess it right, the authors don't have to code it right.

When we no longer require valid code we leave it up to browsers and
user agent to implement a consistent and sufficient fallback mechanism
for invalid code and then look for places where it doesn't work.
We can't expect consistency, after all the code isn't valid in the first place.

This is making our lives and profession harder and seemingly more subjective.


On 8/7/23, Steve Green < <EMAIL REMOVED> > wrote:
> The problem I have with this approach is that neither 2.4.3 nor 4.1.2 appear
> to be violated in the specific case of the website I am testing. However, I
> have only tested with Chrome and NVDA and it is difficult to justify testing
> with more combinations.
>
> With regard to keyboard navigation, the focus indicator for the first tab
> stop encloses both the link and the button. Is that really enough to fail SC
> 2.4.3? The second tab stop only encloses the button, as expected. In both
> cases, pressing the Enter key has the expected behaviour.
>
> I was surprised that the button is exposed correctly via Chrome's
> accessibility tree. My concern is that other browsers might not do the
> same.
>
> Steve
>
>
>