- From: Fred Esch <fesch@us.ibm.com>
- Date: Tue, 19 Jul 2016 15:17:32 -0400
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Cc: "public-aria@w3.org" <public-aria@w3.org>
- Message-Id: <OF480916DC.8359C333-ON85257FF5.00690141-85257FF5.0069FA0D@notes.na.collabserv.c>
Hi Bryan,
In SVG sometimes we want container elements and their children in the
accessibility tree and sometime we don't want a container in the
accessibility tree, but we do want the containers children in the
accessibility tree. The use case in SVG for this is - the container exists
only to pass along rendering properties and isn't semantically important.
We don't consider children of a container that isn't included in the
accessibility tree as orphans, as far as the accessibility tree goes they
end up being children of their closest ancestor in the accessibility tree.
We need this behavior.
What do you mean that you get orphans? Do elements that you want in the
tree not get in the tree?
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: "public-aria@w3.org" <public-aria@w3.org>
Date: 07/19/2016 02:52 PM
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
415.624.2709 (o)
www.SSBBartGroup.com
From: Owen Edwards
Sent: Tuesday, July 19, 2016 11:03 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Mike Schutte <mike.schutte@ssbbartgroup.com>; Sam Joehl
<sam.joehl@ssbbartgroup.com>; Jonathan Avila <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 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 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 or
which have a Required Context Role.
Owen Edwards
Senior Accessibility Consultant
SSB BART Group
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>; Owen Edwards <
owen.edwards@ssbbartgroup.com>; Mike Schutte <mike.schutte@ssbbartgroup.com
>; Sam Joehl <sam.joehl@ssbbartgroup.com>
Cc: AS-All <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>; Mike Schutte <
mike.schutte@ssbbartgroup.com>; Sam Joehl <sam.joehl@ssbbartgroup.com>
Cc: AS-All <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
415.624.2709 (o)
www.SSBBartGroup.com
From: Owen Edwards
Sent: Friday, July 15, 2016 1:13 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Mike Schutte <
mike.schutte@ssbbartgroup.com>; Sam Joehl <sam.joehl@ssbbartgroup.com>
Cc: AS-All <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 J
It actually makes sense that 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
415-814-0524 (office)
From: Bryan Garaventa
Sent: Friday, July 15, 2016 12:49 PM
To: Mike Schutte <mike.schutte@ssbbartgroup.com>; Sam Joehl <
sam.joehl@ssbbartgroup.com>; AS-All <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
415.624.2709 (o)
www.SSBBartGroup.com
From: Mike Schutte
Sent: Friday, July 15, 2016 12:41 PM
To: Sam Joehl <sam.joehl@ssbbartgroup.com>; AS-All <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
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
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
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
415.624.2709 (o)
www.SSBBartGroup.com
From: Mike Schutte
Sent: Thursday, July 14, 2016 10:00 PM
To: Bryan Garaventa <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
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
415.624.2709 (o)
www.SSBBartGroup.com
From: Bryan Garaventa
Sent: Thursday, July 14, 2016 11:51 AM
To: Owen Edwards <owen.edwards@ssbbartgroup.com>
Cc: Mike Schutte <mike.schutte@ssbbartgroup.com>; Jonathan Avila <
jon.avila@ssbbartgroup.com>; AS-All <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.
J
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com
From: Jonathan Avila
Sent: Wednesday, July 13, 2016 12:29 PM
To: Owen Edwards <owen.edwards@ssbbartgroup.com>
Cc: AS-Techs <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>
wrote:
All,
As well as sounding like Yoda wrote it, the BP Ensure lists for
indentation are not used 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
415-814-0524 (office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!
Attachments
- image/gif attachment: 11190581.gif
- image/gif attachment: graycol.gif
Received on Tuesday, 19 July 2016 19:26:15 UTC