E-mail List Archives
Thread: Relationship between WCAG and the ARIA in HTML specification
Number of posts in this thread: 21 (In chronological order)
From: Steve Green
Date: Thu, Aug 03 2023 9:50AM
Subject: Relationship between WCAG and the ARIA in HTML specification
No previous message | Next message →
I am struggling to understand the relationship between WCAG and the ARIA in HTML specification at https://www.w3.org/TR/html-aria/. Do any non-conformances of this specification automatically result in non-conformance of any WCAG success criteria?
I can see how adding inappropriate ARIA attributes to HTML elements could violate WCAG SC 4.1.2 and maybe some other success criteria. However, it's the non-normative section 5 (Allowed descendants of ARIA roles) that I've got a problem with.
At the moment, invalid nesting such as <span role="button" tabindex="0">foo<a href="#">bar</a></span> violates the HTML specification and is a non-conformance of WCAG SC 4.1.1. However, SC 4.1.1 will be removed from WCAG 2.2.
That code is also a non-conformance of the ARIA in HTML specification, but it doesn't appear to translate into a WCAG non-conformance because:
a. It's not even normative under the ARIA in HTML specification.
b. Even if it was normative, which WCAG success criterion would it violate?
And before anyone says no one would write code like that, it's on a website I'm testing and it's actually quite common. I could probably say "just fix it", but I prefer to be able to explain exactly which WCAG success criterion is being violated and how.
Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
= EMAIL ADDRESS REMOVED =
www.testpartners.co.uk
Â
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
From: Birkir R. Gunnarsson
Date: Sun, Aug 06 2023 5:14AM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
ARIA fails that hide the role, state or value of an element should be
exposed as a violation of 4.1.2, I believe.
If the ARIA incorrectly overrides or exposes document structure or
labeling/description relationships you could fail it under 1.3.1, at
least if you can verify the fail. E.g. using the wrong heading level
with ARIA, or building an invalid list with ARIA.
In your example, the button role on the foo span hides the role of the
Bar Link from assistive technologies. The button role, just like the
<button> element strip away all semantics from its descendants and
only leave the text standing, see the presentational children section
of ARIA, somewhere in the roles section.
In other word the button role has effectively turned the link into a
focusable span .. if it is focusable, I'm not even sure.
This is one of the primary reasons I've always been dead set against
removing 4.1.1 from WCAG. I've made such comments on a few threads or
posts related to this decision, but I am too busy for lengthy academic
debates.
I just have to trust that those who made that decision, thought all
this through a lot more than I did.
On 8/3/23, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> I am struggling to understand the relationship between WCAG and the ARIA in
> HTML specification at https://www.w3.org/TR/html-aria/. Do any
> non-conformances of this specification automatically result in
> non-conformance of any WCAG success criteria?
>
> I can see how adding inappropriate ARIA attributes to HTML elements could
> violate WCAG SC 4.1.2 and maybe some other success criteria. However, it's
> the non-normative section 5 (Allowed descendants of ARIA roles) that I've
> got a problem with.
>
> At the moment, invalid nesting such as <span role="button"
> tabindex="0">foo<a href="#">bar</a></span> violates the HTML specification
> and is a non-conformance of WCAG SC 4.1.1. However, SC 4.1.1 will be removed
> from WCAG 2.2.
>
> That code is also a non-conformance of the ARIA in HTML specification, but
> it doesn't appear to translate into a WCAG non-conformance because:
>
> a. It's not even normative under the ARIA in HTML specification.
> b. Even if it was normative, which WCAG success criterion would it violate?
>
> And before anyone says no one would write code like that, it's on a website
> I'm testing and it's actually quite common. I could probably say "just fix
> it", but I prefer to be able to explain exactly which WCAG success criterion
> is being violated and how.
>
> Regards,
> Steve Green
> Managing Director
> Test Partners Ltd
> 020 3002 4176 (direct)
> 0800 612 2780 (switchboard)
> 07957 246 276 (mobile)
> 020 7692 5517 (fax)
> Skype: testpartners
> = EMAIL ADDRESS REMOVED =
> www.testpartners.co.uk
>
> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>
> > > > >
--
Work hard. Have fun. Make history.
From: Patrick H. Lauke
Date: Sun, Aug 06 2023 9:12AM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
On 06/08/2023 12:14, Birkir R. Gunnarsson wrote:
[...]
> This is one of the primary reasons I've always been dead set against
> removing 4.1.1 from WCAG. I've made such comments on a few threads or
> posts related to this decision, but I am too busy for lengthy academic
> debates.
>
> I just have to trust that those who made that decision, thought all
> this through a lot more than I did.
The tl;dr is: invalid markup per se is not a failure. If invalid markup
leads to actual problems for users, then report the problem under the
most appropriate SC that deals with that particular problem.
During the discussions leading to the decision, I don't believe we came
up with problems caused by invalid markup that did not *also* manifest
themselves in other SCs that are more directly tied to user needs.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
From: Birkir R. Gunnarsson
Date: Sun, Aug 06 2023 3:10PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
Yup, y'all thought about it a lot more than I did. ;)
What I like about 4.1.1 is how directly you can do validation and how
easily you can just tie the validation to the markup, no
interpretation required.
Working with developers, this one needed the least amount of
explaining or analysis.
Also this means there's inconsistency in where people pin down use of
ARIA, is it 4.1.2 or 1.3.1 or something else. If the issue is caused
by invalid ARIA markup you could just tie it directly to 4.1.1.
Again, easier, more straight-forward.
In terms of issues not necessarily covered by other SCs the one I hvae
the hardest time tying down is interactive elements nested in links.
You can focus them, typically in the correct focus order.
You can interact with them, at least buttons, I can't 100% speak to
checkboxes/radio buttons or dropdowns.
The issue becomes the screen reader markup again, depends on the
screen reader and user agent, so you have to do extra testing to see
if it really has an impact and with what combinations and then assign
it to 4.1.2, instead of just calling it invalid nesting of interactive
elements, which is not allowed in HTML, and call it a day.
Anyways, like I said, a lot of very smart people spent a lot of itme
thinking about this, so I figure they have thought those scenarios
through.
My main gripe, a perspective from the trenches, is that losing this
criterion makes keeping findings consistent becomes that much harder.
On 8/6/23, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> On 06/08/2023 12:14, Birkir R. Gunnarsson wrote:
> [...]
>> This is one of the primary reasons I've always been dead set against
>> removing 4.1.1 from WCAG. I've made such comments on a few threads or
>> posts related to this decision, but I am too busy for lengthy academic
>> debates.
>>
>> I just have to trust that those who made that decision, thought all
>> this through a lot more than I did.
> The tl;dr is: invalid markup per se is not a failure. If invalid markup
> leads to actual problems for users, then report the problem under the
> most appropriate SC that deals with that particular problem.
>
> During the discussions leading to the decision, I don't believe we came
> up with problems caused by invalid markup that did not *also* manifest
> themselves in other SCs that are more directly tied to user needs.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
> > > > >
--
Work hard. Have fun. Make history.
From: Patrick H. Lauke
Date: Sun, Aug 06 2023 4:10PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
On 06/08/2023 22:10, Birkir R. Gunnarsson wrote:
> Yup, y'all thought about it a lot more than I did. ;)
> What I like about 4.1.1 is how directly you can do validation and how
> easily you can just tie the validation to the markup, no
> interpretation required.
Sure, but that also led to a lot of pointless fails that had no impact
on anything.
Particularly since 4.1.1 didn't mean "valid per the spec", but rather a
concept much closer to XML's "well-formedness" (e.g. that you didn't
misnest opening and closing tags, not whether or not the syntax of HTML
allowed a particular element to be inside another particular element
type). Or rather, that was the original intent, but folks have been
interpreting it differently/away from the original meaning, causing
inconsistency anyway.
> Working with developers, this one needed the least amount of
> explaining or analysis.
But also, it then led to "so how does the fact that I have, say, a <div>
inside a <button> actually affect accessibility" type discussions, where
you ended up having to concede that ok, actually, this one doesn't
really have any impact, but...just do it.
> Also this means there's inconsistency in where people pin down use of
> ARIA, is it 4.1.2 or 1.3.1 or something else. If the issue is caused
> by invalid ARIA markup you could just tie it directly to 4.1.1.
Inconsistency came though because then you either reported it in 4.1.1,
or in whichever SC it actually manifested itself, or in both. Removing
4.1.1 actually makes it hopefully more consistent.
> In terms of issues not necessarily covered by other SCs the one I hvae
> the hardest time tying down is interactive elements nested in links.
> You can focus them, typically in the correct focus order.
I'd argue that focus order is not correct/logical if one is nested
inside the other. That'd be my first port of call for where something
like that fails.
Followed by looking at the keyboard behaviour when activating
things...unless the devs have suppressed bubbling of the event, it
likely ends up causing issues for keyboard users where it triggers
*both* the nested element and the outer link.
Then, as mentioned, the fact that nested interactive elements can end up
with their actual roles/etc overridden, which then yes is a 4.1.2 issue.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
From: Sailesh Panchang
Date: Sun, Aug 06 2023 4:38PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
I went along with the reasoning, "tie the problem caused because of
4.1.1 transgression to another SC" but like Birkir, my preference has
been check code validation first then check for accessibility
violations.
Accessibility aside, IT QA I suppose should also be looking at quality
of code and ensuring code validation would be part of that, no? True,
only a subset of those validation issues may result in accessibility
barriers.
But we are digressing from the question posed in this thread.
Can one say "rrelationship between WCAG and the ARIA in HTML
specification" is no different from the broader relationship between
WCAG and the HTML specs" for instance?
Thanks,
--
Sailesh Panchang
Customer Success Strategist and Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon,
VA 20170
Mobile: 571-344-1765
From: Birkir R. Gunnarsson
Date: Sun, Aug 06 2023 6:52PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
Yeap, I conceit that there are aspects of how 4.1.1 was interpreted
that resulted in a lot of false positives, primarily the duplicate ID
values, (only likely to affects accessibility if it's either used for
labeling, to communicate an informational relationship, or if the
element is a target of JavaScript focus function or CSS selector). Axe
Core does this very well.
But, we digress, I see the point in what you're pointing out Patrick.
I am still concerned that removing this SC is not likely to simplify
accessibility, but I hope it does.
As for the original question. ARIA in HTML is more of an
implementation guide with a mix of normative and best practice
recommendations.
I refer to the rules of ARIA from time to time, with some rewroding,
and I use the HTML to ARIA mapping table in that document all the
time, it is super useful.
So the document is super helpful but I wouldn't consider it a
requirement in its own right.
On 8/6/23, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> I went along with the reasoning, "tie the problem caused because of
> 4.1.1 transgression to another SC" but like Birkir, my preference has
> been check code validation first then check for accessibility
> violations.
> Accessibility aside, IT QA I suppose should also be looking at quality
> of code and ensuring code validation would be part of that, no? True,
> only a subset of those validation issues may result in accessibility
> barriers.
> But we are digressing from the question posed in this thread.
> Can one say "rrelationship between WCAG and the ARIA in HTML
> specification" is no different from the broader relationship between
> WCAG and the HTML specs" for instance?
> Thanks,
> --
> Sailesh Panchang
> Customer Success Strategist and Principal Accessibility Consultant
> Deque Systems Inc
> 381 Elden Street, Suite 2000, Herndon,
> VA 20170
> Mobile: 571-344-1765
> > > > >
--
Work hard. Have fun. Make history.
From: Steve Green
Date: Mon, Aug 07 2023 10:20AM
Subject: Re: Relationship between WCAG and the ARIA in HTMLspecification
← Previous message | Next message →
It was embarrassing to have to report a <div> inside a <span> as a non-conformance of SC 4.1.1, but a <button> element inside an <a> element is another matter completely. It's clearly wrong and SC 4.1.1 made it easy to get things like that fixed.
However, in the absence of SC 4.1.1 it seems we have to prove there is an actual problem, which begs the question how do we do that? How many browser and assistive technology combinations do we need to test? We obviously can't test them all. Perhaps we should try to find some obscure combination that reliably fails, so we only need to test with that one.
It seems we're relying on user agent heuristics to provide a good user experience, but where does that leave us with respect to WCAG's "robustness" requirement? There is no way to be sure that future user agents will handle the invalid code nicely.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Monday, August 7, 2023 1:52 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
Yeap, I conceit that there are aspects of how 4.1.1 was interpreted that resulted in a lot of false positives, primarily the duplicate ID values, (only likely to affects accessibility if it's either used for labeling, to communicate an informational relationship, or if the element is a target of JavaScript focus function or CSS selector). Axe Core does this very well.
But, we digress, I see the point in what you're pointing out Patrick.
I am still concerned that removing this SC is not likely to simplify accessibility, but I hope it does.
As for the original question. ARIA in HTML is more of an implementation guide with a mix of normative and best practice recommendations.
I refer to the rules of ARIA from time to time, with some rewroding, and I use the HTML to ARIA mapping table in that document all the time, it is super useful.
So the document is super helpful but I wouldn't consider it a requirement in its own right.
On 8/6/23, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> I went along with the reasoning, "tie the problem caused because of
> 4.1.1 transgression to another SC" but like Birkir, my preference has
> been check code validation first then check for accessibility
> violations.
> Accessibility aside, IT QA I suppose should also be looking at quality
> of code and ensuring code validation would be part of that, no? True,
> only a subset of those validation issues may result in accessibility
> barriers.
> But we are digressing from the question posed in this thread.
> Can one say "rrelationship between WCAG and the ARIA in HTML
> specification" is no different from the broader relationship between
> WCAG and the HTML specs" for instance?
> Thanks,
> --
> Sailesh Panchang
> Customer Success Strategist and Principal Accessibility Consultant
> Deque Systems Inc
> 381 Elden Street, Suite 2000, Herndon, VA 20170
> Mobile: 571-344-1765
> > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
From: tim.harshbarger@deque.com
Date: Mon, Aug 07 2023 10:35AM
Subject: Re: Relationship between WCAG and the ARIA inHTMLspecification
← Previous message | Next message →
If we have to locate really obscure combinations to try to fail something, is it really a problem then?
It is definitely a question that I find myself thinking about whenever I realize I seem to be looking really hard for a way to fail something and I am having trouble locating it.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, August 7, 2023 11:20 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
It was embarrassing to have to report a <div> inside a <span> as a non-conformance of SC 4.1.1, but a <button> element inside an <a> element is another matter completely. It's clearly wrong and SC 4.1.1 made it easy to get things like that fixed.
However, in the absence of SC 4.1.1 it seems we have to prove there is an actual problem, which begs the question how do we do that? How many browser and assistive technology combinations do we need to test? We obviously can't test them all. Perhaps we should try to find some obscure combination that reliably fails, so we only need to test with that one.
It seems we're relying on user agent heuristics to provide a good user experience, but where does that leave us with respect to WCAG's "robustness" requirement? There is no way to be sure that future user agents will handle the invalid code nicely.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Monday, August 7, 2023 1:52 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
Yeap, I conceit that there are aspects of how 4.1.1 was interpreted that resulted in a lot of false positives, primarily the duplicate ID values, (only likely to affects accessibility if it's either used for labeling, to communicate an informational relationship, or if the element is a target of JavaScript focus function or CSS selector). Axe Core does this very well.
But, we digress, I see the point in what you're pointing out Patrick.
I am still concerned that removing this SC is not likely to simplify accessibility, but I hope it does.
As for the original question. ARIA in HTML is more of an implementation guide with a mix of normative and best practice recommendations.
I refer to the rules of ARIA from time to time, with some rewroding, and I use the HTML to ARIA mapping table in that document all the time, it is super useful.
So the document is super helpful but I wouldn't consider it a requirement in its own right.
On 8/6/23, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> I went along with the reasoning, "tie the problem caused because of
> 4.1.1 transgression to another SC" but like Birkir, my preference has
> been check code validation first then check for accessibility
> violations.
> Accessibility aside, IT QA I suppose should also be looking at quality
> of code and ensuring code validation would be part of that, no? True,
> only a subset of those validation issues may result in accessibility
> barriers.
> But we are digressing from the question posed in this thread.
> Can one say "rrelationship between WCAG and the ARIA in HTML
> specification" is no different from the broader relationship between
> WCAG and the HTML specs" for instance?
> Thanks,
> --
> Sailesh Panchang
> Customer Success Strategist and Principal Accessibility Consultant
> Deque Systems Inc
> 381 Elden Street, Suite 2000, Herndon, VA 20170
> Mobile: 571-344-1765
> > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
From: Steve Green
Date: Mon, Aug 07 2023 11:13AM
Subject: Re: Relationship between WCAG and the ARIAinHTMLspecification
← Previous message | Next message →
It's about minimising the amount of work we need to do. I am suggesting we might start by testing with a combination we expect will exhibit a problem. If it doesn't, there probably isn't much point testing other combinations.
Perhaps "obscure" was the wrong word. I was thinking more of some of the cheaper assistive technologies that perhaps may not handle invalid code nicely. We don't generally test with these because it's difficult enough to test with all the top-end products. But people still use the cheaper products.
And who is to say what proportion of products or combinations need to exhibit a problem before we can report it as a problem? WCAG is silent on this.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, August 7, 2023 5:36 PM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
If we have to locate really obscure combinations to try to fail something, is it really a problem then?
It is definitely a question that I find myself thinking about whenever I realize I seem to be looking really hard for a way to fail something and I am having trouble locating it.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, August 7, 2023 11:20 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
It was embarrassing to have to report a <div> inside a <span> as a non-conformance of SC 4.1.1, but a <button> element inside an <a> element is another matter completely. It's clearly wrong and SC 4.1.1 made it easy to get things like that fixed.
However, in the absence of SC 4.1.1 it seems we have to prove there is an actual problem, which begs the question how do we do that? How many browser and assistive technology combinations do we need to test? We obviously can't test them all. Perhaps we should try to find some obscure combination that reliably fails, so we only need to test with that one.
It seems we're relying on user agent heuristics to provide a good user experience, but where does that leave us with respect to WCAG's "robustness" requirement? There is no way to be sure that future user agents will handle the invalid code nicely.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Monday, August 7, 2023 1:52 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
Yeap, I conceit that there are aspects of how 4.1.1 was interpreted that resulted in a lot of false positives, primarily the duplicate ID values, (only likely to affects accessibility if it's either used for labeling, to communicate an informational relationship, or if the element is a target of JavaScript focus function or CSS selector). Axe Core does this very well.
But, we digress, I see the point in what you're pointing out Patrick.
I am still concerned that removing this SC is not likely to simplify accessibility, but I hope it does.
As for the original question. ARIA in HTML is more of an implementation guide with a mix of normative and best practice recommendations.
I refer to the rules of ARIA from time to time, with some rewroding, and I use the HTML to ARIA mapping table in that document all the time, it is super useful.
So the document is super helpful but I wouldn't consider it a requirement in its own right.
On 8/6/23, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> I went along with the reasoning, "tie the problem caused because of
> 4.1.1 transgression to another SC" but like Birkir, my preference has
> been check code validation first then check for accessibility
> violations.
> Accessibility aside, IT QA I suppose should also be looking at quality
> of code and ensuring code validation would be part of that, no? True,
> only a subset of those validation issues may result in accessibility
> barriers.
> But we are digressing from the question posed in this thread.
> Can one say "rrelationship between WCAG and the ARIA in HTML
> specification" is no different from the broader relationship between
> WCAG and the HTML specs" for instance?
> Thanks,
> --
> Sailesh Panchang
> Customer Success Strategist and Principal Accessibility Consultant
> Deque Systems Inc
> 381 Elden Street, Suite 2000, Herndon, VA 20170
> Mobile: 571-344-1765
> > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
From: glen walker
Date: Mon, Aug 07 2023 12:24PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
I find my time "valuable" and I'm not sure I want to bill the client for
the time I have to think about what SC besides 4.1.1 can I report a problem
under. This won't be an issue until we start testing against 2.2 so I can
still enjoy 4.1.1 for now, but for future testing when I run into nested
button/link elements (which I agree with Steve that I see pretty often), I
will most likely use either 2.4.3 or 4.1.2. I'll pick one or the other and
move on with my testing and try not to lament the loss of 4.1.1.
From: Steve Green
Date: Mon, Aug 07 2023 1:18PM
Subject: Re: Relationship between WCAG and the ARIA in HTMLspecification
← Previous message | Next message →
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
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday, August 7, 2023 7:25 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
I find my time "valuable" and I'm not sure I want to bill the client for the time I have to think about what SC besides 4.1.1 can I report a problem under. This won't be an issue until we start testing against 2.2 so I can still enjoy 4.1.1 for now, but for future testing when I run into nested button/link elements (which I agree with Steve that I see pretty often), I will most likely use either 2.4.3 or 4.1.2. I'll pick one or the other and move on with my testing and try not to lament the loss of 4.1.1.
From: Birkir R. Gunnarsson
Date: Mon, Aug 07 2023 1:42PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
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 ADDRESS 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
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen
> walker
> Sent: Monday, August 7, 2023 7:25 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML
> specification
>
> I find my time "valuable" and I'm not sure I want to bill the client for the
> time I have to think about what SC besides 4.1.1 can I report a problem
> under. This won't be an issue until we start testing against 2.2 so I can
> still enjoy 4.1.1 for now, but for future testing when I run into nested
> button/link elements (which I agree with Steve that I see pretty often), I
> will most likely use either 2.4.3 or 4.1.2. I'll pick one or the other and
> move on with my testing and try not to lament the loss of 4.1.1.
> > > http://webaim.org/discussion/archives
> > > > > >
--
Work hard. Have fun. Make history.
From: Patrick H. Lauke
Date: Mon, Aug 07 2023 1:49PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
On 07/08/2023 20:42, Birkir R. Gunnarsson wrote:
> 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.
They may guess them right, but this one can be checked very easily in
the underlying API: does the browser expose an accessible name for the
input, yes or no? If no (but then the specific AT manages to guess it),
it's still a failure of 4.1.2. That one is quite unambiguous, because
you can't guarantee that all ATs will have the same heuristics.
In the case of misnested/invalid markup, you can guarantee that browsers
all error-correct that markup the same way, since that has been defined
explicitly in the HTML (5/living standard) spec, so not up to heuristics
in browsers anymore, as used to be the case.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
From: Sailesh Panchang
Date: Mon, Aug 07 2023 2:05PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
Most responses so far seem to agree with what I stated earlier:
checking for code validation before doing accessibility testing has
its merits.
And SC 4.1.1 is (or was?) part of the guideline that states: "Maximize
compatibility with current and future user agents, including assistive
technologies".
Does not matter if those are obscure or inexpensive.
Thanks,
Sailesh
On 8/7/23, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 07/08/2023 20:42, Birkir R. Gunnarsson wrote:
>> 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.
>
> They may guess them right, but this one can be checked very easily in
> the underlying API: does the browser expose an accessible name for the
> input, yes or no? If no (but then the specific AT manages to guess it),
> it's still a failure of 4.1.2. That one is quite unambiguous, because
> you can't guarantee that all ATs will have the same heuristics.
>
> In the case of misnested/invalid markup, you can guarantee that browsers
> all error-correct that markup the same way, since that has been defined
> explicitly in the HTML (5/living standard) spec, so not up to heuristics
> in browsers anymore, as used to be the case.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
> > > > >
--
Sailesh Panchang
Customer Success Strategist and Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon,
VA 20170
Mobile: 571-344-1765
From: Steve Green
Date: Mon, Aug 07 2023 5:11PM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
Have they really defined how every type of invalid markup must be handled? Where can I find this? I searched the HTML5 specification but couldn't find anything relevant. Words like "parsing", "invalid" and "error" occur many hundreds of times, so searching was not effective.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: Monday, August 7, 2023 8:49 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
On 07/08/2023 20:42, Birkir R. Gunnarsson wrote:
> 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.
They may guess them right, but this one can be checked very easily in the underlying API: does the browser expose an accessible name for the input, yes or no? If no (but then the specific AT manages to guess it), it's still a failure of 4.1.2. That one is quite unambiguous, because you can't guarantee that all ATs will have the same heuristics.
In the case of misnested/invalid markup, you can guarantee that browsers all error-correct that markup the same way, since that has been defined explicitly in the HTML (5/living standard) spec, so not up to heuristics in browsers anymore, as used to be the case.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
From: Patrick H. Lauke
Date: Tue, Aug 08 2023 2:15AM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
https://html.spec.whatwg.org/#parse-errors
On 08/08/2023 00:11, Steve Green wrote:
> Have they really defined how every type of invalid markup must be handled? Where can I find this? I searched the HTML5 specification but couldn't find anything relevant. Words like "parsing", "invalid" and "error" occur many hundreds of times, so searching was not effective.
>
> Steve
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
> Sent: Monday, August 7, 2023 8:49 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
>
> On 07/08/2023 20:42, Birkir R. Gunnarsson wrote:
>> 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.
>
> They may guess them right, but this one can be checked very easily in the underlying API: does the browser expose an accessible name for the input, yes or no? If no (but then the specific AT manages to guess it), it's still a failure of 4.1.2. That one is quite unambiguous, because you can't guarantee that all ATs will have the same heuristics.
>
> In the case of misnested/invalid markup, you can guarantee that browsers all error-correct that markup the same way, since that has been defined explicitly in the HTML (5/living standard) spec, so not up to heuristics in browsers anymore, as used to be the case.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke > > > > > > --
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
From: Patrick H. Lauke
Date: Tue, Aug 08 2023 2:18AM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
On 08/08/2023 09:15, Patrick H. Lauke wrote:
> https://html.spec.whatwg.org/#parse-errors
Oops, fat finger...meant to point to the overall section
https://html.spec.whatwg.org/#parsing
(this is the part that was never defined in the original HTML spec,
which caused browser engines to just implement their own secret sauce
heuristics when they encountered misnested markup like <b><i>foo</b></i>
- the latter being what 4.1.1 means when it talks about "nested
according to the specification")
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
From: Steve Green
Date: Tue, Aug 08 2023 4:39AM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
I will assume that's a comprehensive list of error conditions - it's certainly a long list. However, it doesn't say anything about the accessibility tree. Is there a specification for how it is constructed? If there is, I can't find it.
Is it possible that different browsers could generate different accessibility trees from the same DOM if the HTML is well formed, but contains invalid nesting? Or does the accessibility tree not take account of an element's nesting?
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: Tuesday, August 8, 2023 9:18 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
On 08/08/2023 09:15, Patrick H. Lauke wrote:
> https://html.spec.whatwg.org/#parse-errors
Oops, fat finger...meant to point to the overall section https://html.spec.whatwg.org/#parsing
(this is the part that was never defined in the original HTML spec, which caused browser engines to just implement their own secret sauce heuristics when they encountered misnested markup like <b><i>foo</b></i>
- the latter being what 4.1.1 means when it talks about "nested according to the specification")
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
From: Birkir R. Gunnarsson
Date: Tue, Aug 08 2023 6:04AM
Subject: Re: Relationship between WCAG and the ARIA in HTML specification
← Previous message | Next message →
I did a very rudimentary test and saw that Firefox and Chrome treat
links with a nested button differently.
* Firefox does not expose a link at all
* Chrome half-exposes a link (Jaws announces the link in browse mode
but not when you open a list of links)
Neither browser exposed the presence of a link nested in a button.
I'll do more comprehensive testing when I have time and throw the
example code up on CodePen or similar.
On 8/8/23, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> I will assume that's a comprehensive list of error conditions - it's
> certainly a long list. However, it doesn't say anything about the
> accessibility tree. Is there a specification for how it is constructed? If
> there is, I can't find it.
>
> Is it possible that different browsers could generate different
> accessibility trees from the same DOM if the HTML is well formed, but
> contains invalid nesting? Or does the accessibility tree not take account of
> an element's nesting?
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Patrick H. Lauke
> Sent: Tuesday, August 8, 2023 9:18 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML
> specification
>
>
>
> On 08/08/2023 09:15, Patrick H. Lauke wrote:
>> https://html.spec.whatwg.org/#parse-errors
>
> Oops, fat finger...meant to point to the overall section
> https://html.spec.whatwg.org/#parsing
>
> (this is the part that was never defined in the original HTML spec, which
> caused browser engines to just implement their own secret sauce heuristics
> when they encountered misnested markup like <b><i>foo</b></i>
> - the latter being what 4.1.1 means when it talks about "nested according to
> the specification")
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
> > > http://webaim.org/discussion/archives
> > > > > >
--
Work hard. Have fun. Make history.
From: Steve Green
Date: Tue, Aug 08 2023 7:44AM
Subject: Re: Relationship between WCAG and the ARIA in HTMLspecification
← Previous message | No next message
It sounds like you are basing your comments on screen reader behaviour rather than the accessibility tree. That's not wrong, but it's important to specify the method because it has a profound effect on the results.
I just tested a button inside a link using the following code:
<p><a href="#">Home</a></p>
<p>Test code</p>
<a href="#">Foo<span role="button" tabindex="0 ">Bar</span></a>
<p>End of test code</p>
The accessibility tree looks the same in Chrome and Firefox insofar as the link and button roles are conveyed correctly. The link's accessible name is the concatenation of the link and button labels, so I can report this as a non-conformance of WCAG SC 4.1.2. It sounds like a trivial issue, but the effect on JAWS and NVDA is extraordinary - they don't seem to be taking any notice of the accessibility tree.
JAWS 2021 gives the following behaviours with Chrome and Firefox:
In virtual cursor mode the word "Foo" just appears to be text, not a link.
When tabbing, the "Foo" link is announced as the previously focusable element i.e. neither its name nor role is announced. In my test page it is announced as "Home link" when tabbing forwards and as "Bar button" when tabbing backwards.
When tabbing forwards, the "Bar" button is correctly announced as "Bar button". But tabbing backwards, it is announced as "FooBar link Bar button".
In both cases, the "Bar" button is announced correctly.
With NVDA 2021 (with Screen Layout turned off), I get the following with Chrome and Firefox:
In virtual cursor mode the "Foo" link is announced as "Link Foo". The "Bar" button is announced as "Link button Bar".
When tabbing forwards, the "Foo" link is announced as "Foo Bar link". The "Bar" button is announced as "Bar button link".
When tabbing backwards, the "Foo" link is a silent tab stop. The "Bar" button is announced as "Bar button link".
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Tuesday, August 8, 2023 1:04 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification
I did a very rudimentary test and saw that Firefox and Chrome treat links with a nested button differently.
* Firefox does not expose a link at all
* Chrome half-exposes a link (Jaws announces the link in browse mode but not when you open a list of links) Neither browser exposed the presence of a link nested in a button.
I'll do more comprehensive testing when I have time and throw the example code up on CodePen or similar.
On 8/8/23, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> I will assume that's a comprehensive list of error conditions - it's
> certainly a long list. However, it doesn't say anything about the
> accessibility tree. Is there a specification for how it is
> constructed? If there is, I can't find it.
>
> Is it possible that different browsers could generate different
> accessibility trees from the same DOM if the HTML is well formed, but
> contains invalid nesting? Or does the accessibility tree not take
> account of an element's nesting?
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Patrick H. Lauke
> Sent: Tuesday, August 8, 2023 9:18 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML
> specification
>
>
>
> On 08/08/2023 09:15, Patrick H. Lauke wrote:
>> https://html.spec.whatwg.org/#parse-errors
>
> Oops, fat finger...meant to point to the overall section
> https://html.spec.whatwg.org/#parsing
>
> (this is the part that was never defined in the original HTML spec,
> which caused browser engines to just implement their own secret sauce
> heuristics when they encountered misnested markup like
> <b><i>foo</b></i>
> - the latter being what 4.1.1 means when it talks about "nested
> according to the specification")
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.