- From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
- Date: Tue, 19 Jul 2016 15:09:42 -0400
- To: "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>, <public-aria@w3.org>
- Message-ID: <01df01d1e1f1$1c37ec50$54a7c4f0$@deque.com>
A different version of the same problem is when a structural role is applied to the parent, the children are still alive and well.
Consider:
<ul role=”menu”>
<li><a href=”#” role=”menuitem”>Menu item 1</a></li>
<li><a href=”#” role=”menuitem”>Menu item 2</a></li>
</ul>
The assistive technology still announcedsindividual menu items as “1 of 1” because of the <li> role, so role=”presentation” is required on those roles to really wipe out the remaped list markup.
I believe this is true in all user agents/a.t. combinations I have tested with.
It is hard to ssay with Jaws, because Jaws does not automatically announce the number of children.
It shouldn’t be needed.
If the ul element is mapped as something else, its child <li> elements should be made presentational.
-B
This might be different enough to warrant its own issue, but I think the root cause is the same.
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Tuesday, July 19, 2016 2:27 PM
To: public-aria@w3.org
Subject: Prior to filing ARIA 2.0 bug for structural elements not processing owned children within the accessibility tree
I wanted to pass this scenario along since it’s been coming up for us a lot lately.
Basically, when role=presentation is applied to a structural element like an HTML ul, ol, dl, table, etc, logic exists within the processing to handle owned children like li, dd, dt, tr, th, td, and so on in the accessibility tree.
However no such processing exists for any other role applied to the same structural elements, causing orphaned children all over the place.
We have to watch out for the orphans…
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com <http://www.SSBBartGroup.com>
From: Owen Edwards
Sent: Tuesday, July 19, 2016 11:03 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> >
Cc: Mike Schutte <mike.schutte@ssbbartgroup.com <mailto:mike.schutte@ssbbartgroup.com> >; Sam Joehl <sam.joehl@ssbbartgroup.com <mailto:sam.joehl@ssbbartgroup.com> >; Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com> >
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Bryan,
Just to follow up on this, the following simple example gets flagged by https://validator.w3.org/nu/:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Test title</title>
</head>
<body>
<div>
<ul role="navigation">
<li><a href="/here.html">Here</a></li>
<li><a href="/there.html">There</a></li>
<li><a href="anywhere.html">Anywhere</a></li>
</ul>
</div>
</body>
</html>
1. Error: Bad value navigation for attribute role on element <http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-ul-element> ul.
<div>↩ <ul role="navigation">↩
Whereas, as suggested, moving the navigation role to the <DIV> does not get flagged:
...
<div role="navigation">
<ul>
<li><a href="/here.html">Here</a></li>
<li><a href="/there.html">There</a></li>
<li><a href="anywhere.html">Anywhere</a></li>
</ul>
</div>
...
However, the alternative solution of adding a role of presentation to the <LI> is also flagged as invalid:
...
<div>
<ul role="navigation">
<li role="presentation"><a href="/here.html">Here</a></li>
<li role="presentation"><a href="/there.html">There</a></li>
<li role="presentation"><a href="anywhere.html">Anywhere</a></li>
</ul>
</div>
...
1. Error: Bad value navigation for attribute role on element <http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-ul-element> ul.
<div>↩ <ul role="navigation">↩
(This is certainly an issue of the Validator, rather than the standards).
But I wonder how common the <ul role="navigation"> pattern is in the wild?
I understand that W3C documents cannot list every possible implementation error, but in the spirit of ARIA improving accessibility rather than making it worse, it seems important to emphasize that Landmark Roles, like other roles, replace the native role of an element (rather than adding to the native role, which I think may be why this error happens), and should therefore be used carefully on elements with Required Owned Elements <http://w3c.github.io/aria/aria/aria.html#mustContain> or which have a Required Context Role <http://w3c.github.io/aria/aria/aria.html#scope> .
Owen Edwards
Senior Accessibility Consultant
SSB BART Group
Owen.Edwards@SSBBARTGroup.com <mailto:Owen.Edwards@SSBBARTGroup.com>
415-814-0524 (office)
From: Matt King [mailto:mck@fb.com]
Sent: Sunday, July 17, 2016 7:26 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> >; Owen Edwards <owen.edwards@ssbbartgroup.com <mailto:owen.edwards@ssbbartgroup.com> >; Mike Schutte <mike.schutte@ssbbartgroup.com <mailto:mike.schutte@ssbbartgroup.com> >; Sam Joehl <sam.joehl@ssbbartgroup.com <mailto:sam.joehl@ssbbartgroup.com> >
Cc: AS-All <as-all@ssbbartgroup.com <mailto:as-all@ssbbartgroup.com> >
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Bryan,
The <ul role=”navigation”> construct should definitely create a validation error. Whether it is one that browsers should “repair” by treating descendant <li> elements as presentational is probably going to create an interesting working group discussion. I am not sure where that would land as it has quite a few implications.
In general, when it comes to coding, the APG does not tell readers what not to do but instead focuses on what authors should be doing. So, I am not sure where guidance like this may fit. It is not necessarily a landmark issue as you would have the same kind of problem if you did <ul role=”dialog”> or <ul role=”document”>.
If you really think this is something we need to address in the APG, the best thing to do is raise an APG issue:
https://github.com/w3c/aria-practices/issues
That way, we will not lose track of it.
Even better, if you have an idea on how to address it, describe that idea in the issue or submit a pull request with your proposal.
Best,
Matt
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Friday, July 15, 2016 1:22 PM
To: Owen Edwards <owen.edwards@ssbbartgroup.com <mailto:owen.edwards@ssbbartgroup.com> >; Mike Schutte <mike.schutte@ssbbartgroup.com <mailto:mike.schutte@ssbbartgroup.com> >; Sam Joehl <sam.joehl@ssbbartgroup.com <mailto:sam.joehl@ssbbartgroup.com> >
Cc: AS-All <as-all@ssbbartgroup.com <mailto:as-all@ssbbartgroup.com> >
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
“Bryan, if the ARIA WG is going to be slow on this, can you create something which clarifies it for SSB’s own use (which will perhaps ultimately become part of ARIA 1.x)?”
I’ll see if we can get this into the APG 1.1 for documenting best practices for landmarks and regions.
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com <http://www.SSBBartGroup.com>
From: Owen Edwards
Sent: Friday, July 15, 2016 1:13 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> >; Mike Schutte <mike.schutte@ssbbartgroup.com <mailto:mike.schutte@ssbbartgroup.com> >; Sam Joehl <sam.joehl@ssbbartgroup.com <mailto:sam.joehl@ssbbartgroup.com> >
Cc: AS-All <as-all@ssbbartgroup.com <mailto:as-all@ssbbartgroup.com> >
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Thanks for the summary Bryan; the nail on the head I think that hits :)
It actually makes sense that Landmark Roles <https://www.w3.org/TR/wai-aria/roles#landmark_roles> don’t affect child nodes, because those child nodes should not become landmarks themselves (they are within a landmark region, but not landmarks themselves). But I agree that the spec could be clearer on this, and whether role=presentation is needed on those children.
So, as a broader summary; the initial issue about the BP being flagged was because list elements (LI) must be the immediate (first-level) children of lists (UL or OL); having intervening <DIV>s is an HTML violation which causes AMP to flag an automatic “Ensure lists for indentation are not used” violation. This isn’t so much a false positive as, perhaps, a side effect of the fact that a site’s HTML is not passed through a validator before being run through AMP, and AMPs reaction to invalid code can be unpredictable (I’ve seen it totally thrown off by an missing </LI> closing tag!)
So perhaps we should look again at whether AMP should run the HTML through a validator, and provide the results of part of the report under WCAG 4.1.1? This could clarify flagged BPs where the underlying issue relates to invalid HTML, without testers needing to manually look at or validate the code.
The secondary issue of applying a Landmark role to an element which has required children, and this “orphaning” those children, need clearer documentation; Bryan, if the ARIA WG is going to be slow on this, can you create something which clarifies it for SSB’s own use (which will perhaps ultimately become part of ARIA 1.x)?
Owen Edwards
Senior Accessibility Consultant
SSB BART Group
Owen.Edwards@SSBBARTGroup.com <mailto:Owen.Edwards@SSBBARTGroup.com>
415-814-0524 (office)
From: Bryan Garaventa
Sent: Friday, July 15, 2016 12:49 PM
To: Mike Schutte <mike.schutte@ssbbartgroup.com <mailto:mike.schutte@ssbbartgroup.com> >; Sam Joehl <sam.joehl@ssbbartgroup.com <mailto:sam.joehl@ssbbartgroup.com> >; AS-All <as-all@ssbbartgroup.com <mailto:as-all@ssbbartgroup.com> >
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Unfortunately this is one of those weird areas that seems logical but isn’t.
So role=presentational as with role=none do apply to first level inherited children, but no other roles do the same.
So the following works:
<ul role=”presentation”>
However this does not:
<ul role=”navigation”>
Where the first will cancel out all child LI roles, but the second will not.
It seems logical that both would do the same, but this is what is not documented in the spec, so we have to do this manually using role=”presentation” on the Lis on the second example to cover this in all other role implementations like this for this purpose.
I raised this as an issue not long ago, but doing this was too complicated in the ARIA 1.1 timeline so I’ll have to revisit this later.
Hopefully this helps summarize the problem.
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com <http://www.SSBBartGroup.com>
From: Mike Schutte
Sent: Friday, July 15, 2016 12:41 PM
To: Sam Joehl <sam.joehl@ssbbartgroup.com <mailto:sam.joehl@ssbbartgroup.com> >; AS-All <as-all@ssbbartgroup.com <mailto:as-all@ssbbartgroup.com> >
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Sam, I know it’s stated in the spec for role=”presentation” because I found it there, all nice and explicit, and copied the passage into my email.
It was _all the others_ that I was asking about.
Bryan answered that question: “…of course it’s not”!
Mike Schutte
Senior Director of Accessibility Services
<mailto:mike.schutte@ssbbartgroup.com> mike.schutte@ssbbartgroup.com
(415) 624-2702 (o)
From: Sam Joehl
Sent: Friday, July 15, 2016 12:24 PM
To: AS-All
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Mike,
It’s right in the spec. If role=presentation is placed on a parent element that has required owned elements, then the user agent is required to apply the presentation role to the required owned elements as well.
http://www.w3.org/TR/wai-aria/roles#presentation
Best regards,
Sam Joehl
SSB BART Group
(703) 637-8956
Sam.joehl@ssbbartgroup.com <mailto:Sam.joehl@ssbbartgroup.com>
From: Mike Schutte
Sent: Friday, July 15, 2016 3:12 PM
To: Bryan Garaventa
Cc: AS-All
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
I understood from Jon’s and your replies that the <li> tags were orphaned in the cited example.
My question, though, was whether or where in the ARIA reference pages for roles, states & properties it’s indicated which ones only affect the current element, like role=”presentation”, and which affect “all” child elements as well. Is that documented?
Mike Schutte
Senior Director of Accessibility Services
<mailto:mike.schutte@ssbbartgroup.com> mike.schutte@ssbbartgroup.com
(415) 624-2702 (o)
From: Bryan Garaventa
Sent: Friday, July 15, 2016 10:19 AM
To: Mike Schutte
Cc: AS-All
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Actually no, you are right, in that putting the role on the UL or OL will orphan the Lis within the structure.
E.G The following markup:
<ul role=”navigation”>
<li>
One
</li>
<li>
Two
</li>
</ul>
Is equivalent to the following:
<nav>
<li>
One
</li>
<li>
Two
</li>
</nav>
Which is an invalid structure because it includes orphaned Lis. So the Lis would need to include role=presentation to nullify them in the accessibility tree if done to prevent this.
Does that make more sense?
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com <http://www.SSBBartGroup.com>
From: Mike Schutte
Sent: Thursday, July 14, 2016 10:00 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> >
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Mmmmm….crow! Yum!
So I was wrong about the role=”navigation” on the <ul> negated the structural semantics of he enclosed <li> tags, as both you and Jon said it does not.
Where is the best reference place to identify which ARIA roles, states & properties DO trickle down to child elements and which only impact the element it’s in? The ARIA 1.1 spec goes out of its way to describe this for role=”presentation”, but what about everything else?
For any element with a role of presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of presentation. Thus, the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.
Seems like they could include that as a row in the Characteristics table for each role/state/property – or am I missing where it’s indicated already?
Mike Schutte
Senior Director of Client Services
<mailto:mike.schutte@ssbbartgroup.com> mike.schutte@ssbbartgroup.com
(415) 624-2702 (o)
From: Bryan Garaventa
Sent: Thursday, July 14, 2016 11:52 AM
To: Owen Edwards
Cc: Mike Schutte; Jonathan Avila; AS-All
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Sorry, technically okay it is…
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com <http://www.SSBBartGroup.com>
From: Bryan Garaventa
Sent: Thursday, July 14, 2016 11:51 AM
To: Owen Edwards <owen.edwards@ssbbartgroup.com <mailto:owen.edwards@ssbbartgroup.com> >
Cc: Mike Schutte <mike.schutte@ssbbartgroup.com <mailto:mike.schutte@ssbbartgroup.com> >; Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com> >; AS-All <as-all@ssbbartgroup.com <mailto:as-all@ssbbartgroup.com> >
Subject: RE: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
Hi,
Technically it is okay to use role=navigation on a UL or OL, with the understanding that you are destroying the underlying list structure, so it may be necessary to also add role=”presentation” to each LI to prevent these from being orphaned in the accessibility tree.
If it sounds better to maintain a list for AT users, then yes, adding role=navigation on a surrounding element like a Div would be the way to go.
:)
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com <http://www.SSBBartGroup.com>
From: Jonathan Avila
Sent: Wednesday, July 13, 2016 12:29 PM
To: Owen Edwards <owen.edwards@ssbbartgroup.com <mailto:owen.edwards@ssbbartgroup.com> >
Cc: AS-Techs <as-techs@ssbbartgroup.com <mailto:as-techs@ssbbartgroup.com> >
Subject: Re: A false positive this seems to be! (BP: Ensure lists for indentation are not used)
I'd have to look at why this was being flagged but I would recommend against using role navigation on the Ul as then we might have orphaned lI Elemwnts in the accessibility tree. They should use a div with role navigation around the Ul.
Bryan do you agree with this?
Jon
Sent from my iPhone
On Jul 13, 2016, at 3:18 PM, Owen Edwards <owen.edwards@ssbbartgroup.com <mailto:owen.edwards@ssbbartgroup.com> > wrote:
All,
As well as sounding like Yoda wrote it, the BP Ensure lists for indentation are not used <https://amp.ssbbartgroup.com/public/standards/view_best_practice.php?violation_id=394> gives these two compliant examples:
Compliant Example
<style type="text/css">
p { margin: 5ems}
</style>
<p>
Content to be indented.
</p>
<ol role="presentation">
Content to be indented.
</ol>
My client has a navigation header with this structure:
<ul role="navigation" class="headerNav">
<div class="...">
<li>
<a class="navAt" href="...">HOME</a>
</li>
</div>
<div class="...">
<li>
<a class="..." href="...">ENROLL</a>
</li>
</div>
<div class="...">
<li>
<a class="..." href="...">MY PROFILE</a>
</li>
</div>
...
</ul>
which gets automatically flagged on every page as a violation of that BP.
Does the role="navigation" have the same effect as the role="presentation" in the second compliant example? Would other landmark roles have the same effect?
Thanks!
Owen Edwards
Senior Accessibility Consultant
SSB BART Group
Owen.Edwards@SSBBARTGroup.com <mailto:Owen.Edwards@ssbbartgroup.com>
415-814-0524 (office)
Visit us online: <http://www.ssbbartgroup.com/> Website | <https://twitter.com/SSBBARTGroup> Twitter | <https://www.facebook.com/ssbbartgroup> Facebook | <https://www.linkedin.com/company/355266?trk=tyah> Linkedin | <http://www.ssbbartgroup.com/blog/> Blog
<http://www.ssbbartgroup.com/webinars/> Check out our Digital Accessibility Webinars!
Received on Tuesday, 19 July 2016 19:10:13 UTC