- From: Aaron Leventhal <aleventhal@google.com>
- Date: Wed, 24 May 2017 14:34:28 +0000
- To: Ann Abbott <aabbott@us.ibm.com>
- Cc: Matt King <a11ythinker@gmail.com>, Alexander Surkov <asurkov@mozilla.com>, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, david bolter <david.bolter@gmail.com>, Dominic Mazzoni <dmazzoni@google.com>, James Nurthen <james.nurthen@oracle.com>, James Craig <jcraig@apple.com>, Marco Zehe <marco.zehe@gmail.com>, ARIA Working Group <public-aria@w3.org>, Rich Schwerdtfeger <richschwer@gmail.com>
- Message-ID: <CA+1LECTKvD5k=0bZ+dRUat6pGMWhB2e9xZ8ggYpBHwtRj4oTAA@mail.gmail.com>
Ok, here goes :)
This is a mix of ARIA and internal roles. I have not removed internal role
names we use. I myself am still learning what some of them are as I'm new
to the Chrome codebase. I'm happy to look up what any of them are if people
have questions. Also, feel free to critique which category things are in.
We just wrote this code with the intentions of being more like Firefox, and
it may not be perfect.
With respect to 'name from content', Chrome divides all roles (ARIA and
otherwise) into 3 neat categories:
1. *Always* allow name from contents and always contribute to ancestor name
from contents. These are mostly focusable widgets.
anchor, button, cell, checkbox, columnheader, disclosuretriangle, heading,
linebreak, link, listboxoption, menubutton, menuitem, menuitemcheckbox,
menuitemradio, menulistoption
popupbutton, radiobutton, rowheader, statictext, switch, tab, togglebutton,
treeitem, userinterfacetooltip
2. *Never *allow name from contents and never contribute to ancestor name
from contents. This includes composite widgets that tend to have a lot of
focusable children. I think of these as "strongly nameless". They can only
get a name from author.
alert, alertdialog, application, audio, article, banner, blockquote,
colorwell, column, combobox, complementary, contentinfo, date, datetime,
definition, dialog, directory, document, embeddedobject, feed, figure,
form, grid, group, iframepresentational, iframe, image, inputtime, listbox,
log, main, marquee, math, menulistpopup, menu, menubar, meter, navigation,
note, outline, progressindicator, radiogroup, region, rootwebarea,
scrollbar, search, searchbox, splitter, slider, spinbutton, status,
scrollarea, seamlesswebarea, sliderthumb, spinbuttonpart, svgroot, table,
tableheadercontainer, tabgroup, tablist, tabpanel, term, textfield, time,
timer, toolbar, tree, treegrid, video, webarea, window
3. *Conditionally *allow name from contents if A) contributing to ancestor
or B) focusable (but not editable as a name is redundant in that case).
The includes a lot of roles used for document semantics. I think of them as
being "weakly nameless". They don't generally need a name unless you focus
them, but they should also pass their contents up to ancestors seeking name
from contents.
abbr, annotation, busyindicator, canvas, caption, descriptionlistdetail,
descriptionlist, descriptionlistterm, details, figcaption, footer,
genericcontainer, ignored
imagemaplink, imagemap, inlinetextbox, label, legend, list, listitem,
listmarker, mark, none, paragraph, pre, presentational, row, ruby, ruler
- A "genericcontainer" is used for something like a <div> where we need to
expose it because it is focusable or has ARIA semantics, but has no other
role.
- Note: according to the spec "row" should be in category 1, but for
performance/memory reasons we put it in category 3, in order to avoid lots
of names for non-focusable table rows, where it wouldn't be helpful.
Aaron
On Tue, May 23, 2017 at 4:27 PM Ann Abbott <aabbott@us.ibm.com> wrote:
> Hi Aaron -
>
> I'm definitely interested in the list you mention providing - and my head
> won't explode upon receipt! That event already occurred trying to
> understand the impact of the 508 Refresh combined with EN 301 549 and WCAG
> 2.0 - BLEH!
>
>
> Kind Regards,
>
> Ann Abbott
> IBM Collaboration Solutions Accessibility Lead
> Member: *International Association of Accessibility Professionals (IAAP)*
> <http://www.accessibilityassociation.org/>
> Member: W3C WAI-ARIA 1.1 Authoring Practices Guide Working Group
>
> Tieline 363-5002
> Direct 512-286-5002 <(512)%20286-5002>
> *aabbott@us.ibm.com* <aabbott@us.ibm.com>
> “It always seems impossible until it's done.”
>
> ― Nelson Mandela
>
> 18 July 1918 – 5 December 2013
>
>
>
> [image: graycol.gif]Aaron Leventhal ---05/23/2017 02:38:33 PM---That's
> fine Bryan, I agree we have to do a better job of explaining. I can only
> imagine how hard tha
>
> From: Aaron Leventhal <aleventhal@google.com>
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, Matt King <
> a11ythinker@gmail.com>, James Nurthen <james.nurthen@oracle.com>, ARIA
> Working Group <public-aria@w3.org>, Dominic Mazzoni <dmazzoni@google.com>,
> Marco Zehe <marco.zehe@gmail.com>, Rich Schwerdtfeger <
> richschwer@gmail.com>, david bolter <david.bolter@gmail.com>, Alexander
> Surkov <asurkov@mozilla.com>, James Craig <jcraig@apple.com>
> Date: 05/23/2017 02:38 PM
> Subject: Re: Important concerns with naming calculation 'name from
> content' not being included in parent role accessible name.
> ------------------------------
>
>
>
>
> That's fine Bryan, I agree we have to do a better job of explaining. I can
> only imagine how hard that is, given the fact that although we do try to
> spec things, there seem to be a lot of hidden smarts in the browsers
> anyway, not to mention edge cases. So keep poking us. The rules attempt to
> do what you'd intuitively want as a developer, and that may lead to some
> interesting nuance or edge cases. It may not always be perfect.
>
> The way Chrome and Firefox handles your above examples is that for
> nameless generic document structure roles (not widgets), they are not
> strongly nameless. They are allowed to contribute to ancestor
> name-from-contents, even though they don't have their own name. As my
> colleague Alice Boxhall noticed, this seems to not be in the spec but
> should be.
>
> So for example, list item contents would still contribute to a heading
> name, but if it was a listbox widget, it would not.
>
> I'm happy to provide a list of roles that we do this for, as long as it
> doesn't make anyone's head explode.
>
> Aaron
>
> On Tue, May 23, 2017 at 3:19 PM Bryan Garaventa <
> *bryan.garaventa@ssbbartgroup.com* <bryan.garaventa@ssbbartgroup.com>>
> wrote:
>
> Hi,
> I'm not trying to belabor this, but I have to explain this to
> developers, and I'm still seeing potential issues with this.
>
> So to be clear, if the recursive 'name from content' algorithm for a
> valid role does not include the name of any child elements that are set as
> 'name from content' = false, then this rule applies to all of the following
> roles according to the spec. (Including all implicit roles with these
> mappings as well)
>
> cell
> columnheader
> gridcell
> header
> link
> menuitem
> row
> rowgroup
> rowheader
> tooltip
> treeitem
>
> I've seen examples of headings that include lists of links within
> them, as well as tooltips that include a list of checklist criteria within
> them, and according to this algorithm this would cause such elements to
> omit this content from the accessible names of each.
>
> So, though there are many roles below that don't make sense to be
> embedded as children of the above listed roles, there are many that do
> however, and are automatically mapped by the browsers when certain HTML
> elements are used by themselves.
>
> So can you say that the above roles will never or should never include
> child elements with the below roles, and if they do then it is acceptable
> to ignore their content when calculating the names of the above roles?
>
> alert
> alertdialog
> application
> article
> banner
> combobox
> complementary
> contentinfo
> definition
> dialog
> directory
> document
> feed
> figure
> form
> grid
> group
> img
> list
> listitem
> listbox
> log
> main
> marquee
> math
> menu
> menubar
> navigation
> note
> progressbar
> radiogroup
> region
> scrollbar
> search
> searchbox
> separator
> slider
> spinbutton
> status
> table
> tablist
> tabpanel
> term
> textbox
> timer
> toolbar
> tree
> treegrid
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> *bryan.garaventa@ssbbartgroup.com* <bryan.garaventa@ssbbartgroup.com>
> *415.624.2709* <(415)%20624-2709> (o)
> *www.SSBBartGroup.com* <http://www.ssbbartgroup.com/>
>
> -----Original Message-----
> From: Bryan Garaventa [mailto:*bryan.garaventa@ssbbartgroup.com*
> <bryan.garaventa@ssbbartgroup.com>]
> Sent: Monday, May 22, 2017 3:23 PM
> To: Matt King <*a11ythinker@gmail.com* <a11ythinker@gmail.com>>;
> 'James Nurthen' <*james.nurthen@oracle.com* <james.nurthen@oracle.com>>;
> 'ARIA Working Group' <*public-aria@w3.org* <public-aria@w3.org>>;
> *aleventhal@google.com* <aleventhal@google.com>; 'Dominic Mazzoni' <
> *dmazzoni@google.com* <dmazzoni@google.com>>; 'Marco Zehe' <
> *marco.zehe@gmail.com* <marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <
> *richschwer@gmail.com* <richschwer@gmail.com>>; 'david bolter' <
> *david.bolter@gmail.com* <david.bolter@gmail.com>>; 'Alexander Surkov'
> <*asurkov@mozilla.com* <asurkov@mozilla.com>>; 'James Craig' <
> *jcraig@apple.com* <jcraig@apple.com>>
> Subject: RE: Important concerns with naming calculation 'name from
> content' not being included in parent role accessible name.
>
> In going through the spec to identify which roles are which for this
> purpose, there is a discrepancy in the section "5.2.7.5 Roles Supporting
> Name from Content", where role=tree is listed as supporting this, even
> though it is not supported when viewing the section for role=tree.
>
> 'tree' should be removed from the list in section 5.2.7.5.
>
> I've documented all of the relevant roles that apply with this
> exception below.
>
> Roles with 'children presentational' = true button checkbox img math
> menuitemcheckbox menuitemradio option progressbar radio scrollbar separator
> slider switch tab
>
> So browsers should not restrict the 'name from content' if any of the
> following explicit or implicit roles are embedded within any of the
> previous explicit or implicit roles. (I'm not saying they are valid
> children, just referring to the naming calculation if this exception is
> applied equally as we spoke of.)
>
> Roles with 'name from content' = false
> alert
> alertdialog
> application
> article
> banner
> combobox
> complementary
> contentinfo
> definition
> dialog
> directory
> document
> feed
> figure
> form
> grid
> group
> img
> list
> listitem
> listbox
> log
> main
> marquee
> math
> menu
> menubar
> navigation
> note
> progressbar
> radiogroup
> region
> scrollbar
> search
> searchbox
> separator
> slider
> spinbutton
> status
> table
> tablist
> tabpanel
> term
> textbox
> timer
> toolbar
> tree
> treegrid
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> *bryan.garaventa@ssbbartgroup.com* <bryan.garaventa@ssbbartgroup.com>
> *415.624.2709* <(415)%20624-2709> (o)
> *www.SSBBartGroup.com* <http://www.ssbbartgroup.com/>
>
> -----Original Message-----
> From: Matt King [mailto:*a11ythinker@gmail.com* <a11ythinker@gmail.com>
> ]
> Sent: Thursday, May 18, 2017 3:52 PM
> To: Bryan Garaventa <*bryan.garaventa@ssbbartgroup.com*
> <bryan.garaventa@ssbbartgroup.com>>; 'James Nurthen' <
> *james.nurthen@oracle.com* <james.nurthen@oracle.com>>; 'ARIA Working
> Group' <*public-aria@w3.org* <public-aria@w3.org>>;
> *aleventhal@google.com* <aleventhal@google.com>; 'Dominic Mazzoni' <
> *dmazzoni@google.com* <dmazzoni@google.com>>; 'Marco Zehe' <
> *marco.zehe@gmail.com* <marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <
> *richschwer@gmail.com* <richschwer@gmail.com>>; 'david bolter' <
> *david.bolter@gmail.com* <david.bolter@gmail.com>>; 'Alexander Surkov'
> <*asurkov@mozilla.com* <asurkov@mozilla.com>>; 'James Craig' <
> *jcraig@apple.com* <jcraig@apple.com>>
> Subject: RE: Important concerns with naming calculation 'name from
> content' not being included in parent role accessible name.
>
> While the name calculation algorithm is conceptually simple, it would
> be a stretch to say that every conditional branch is clear. We've
> definitely been mining some gems over the course of the last year or so.
>
> WRT naming, It would be illogical to say that children presentational
> is nonconsequential.
>
> "2. f. Otherwise, if the current node's role allows name from content,
> or if the current node is referenced by aria-labelledby, aria-describedby,
> or is a native host language text alternative element:"
>
> When a table or list is nested in a button, it acquires role
> presentation.
> So, when that table or list becomes the current node in the name
> calculation, it allows name from content.
>
> That seems reasonably clear to me.
>
> Matt
>
> -----Original Message-----
> From: Bryan Garaventa [mailto:*bryan.garaventa@ssbbartgroup.com*
> <bryan.garaventa@ssbbartgroup.com>]
> Sent: Thursday, May 18, 2017 1:43 PM
> To: Matt King <*a11ythinker@gmail.com* <a11ythinker@gmail.com>>;
> 'James Nurthen'
> <*james.nurthen@oracle.com* <james.nurthen@oracle.com>>; 'ARIA Working
> Group' <*public-aria@w3.org* <public-aria@w3.org>>;
> *aleventhal@google.com* <aleventhal@google.com>; 'Dominic Mazzoni' <
> *dmazzoni@google.com* <dmazzoni@google.com>>; 'Marco Zehe'
> <*marco.zehe@gmail.com* <marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <
> *richschwer@gmail.com* <richschwer@gmail.com>>; 'david bolter' <
> *david.bolter@gmail.com* <david.bolter@gmail.com>>; 'Alexander Surkov'
> <*asurkov@mozilla.com* <asurkov@mozilla.com>>; 'James Craig' <
> *jcraig@apple.com* <jcraig@apple.com>>
> Subject: RE: Important concerns with naming calculation 'name from
> content'
> not being included in parent role accessible name.
>
> Thanks,
> That makes sense to me as well.
>
> At present however the accessible name of the tab is null (""), and
> there is nothing conveyed in the accessibility tree as the name for the tab
> in Firefox regardless.
>
> So are we all in agreement then, that if children presentational is
> true on a specific role, then it doesn't matter if name from content is
> missing from a child construct role?
>
> Is this actually clearly conveyed in the naming calculation?
>
> Thanks,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> *bryan.garaventa@ssbbartgroup.com* <bryan.garaventa@ssbbartgroup.com>
> *415.624.2709* <(415)%20624-2709> (o)
> *www.SSBBartGroup.com* <http://www.ssbbartgroup.com/>
>
> -----Original Message-----
> From: Matt King [mailto:*a11ythinker@gmail.com* <a11ythinker@gmail.com>
> ]
> Sent: Thursday, May 18, 2017 12:20 PM
> To: Bryan Garaventa <*bryan.garaventa@ssbbartgroup.com*
> <bryan.garaventa@ssbbartgroup.com>>; 'James Nurthen'
> <*james.nurthen@oracle.com* <james.nurthen@oracle.com>>; 'ARIA Working
> Group' <*public-aria@w3.org* <public-aria@w3.org>>;
> *aleventhal@google.com* <aleventhal@google.com>; 'Dominic Mazzoni' <
> *dmazzoni@google.com* <dmazzoni@google.com>>; 'Marco Zehe'
> <*marco.zehe@gmail.com* <marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <
> *richschwer@gmail.com* <richschwer@gmail.com>>; 'david bolter' <
> *david.bolter@gmail.com* <david.bolter@gmail.com>>; 'Alexander Surkov'
> <*asurkov@mozilla.com* <asurkov@mozilla.com>>; 'James Craig' <
> *jcraig@apple.com* <jcraig@apple.com>>
> Subject: RE: Important concerns with naming calculation 'name from
> content'
> not being included in parent role accessible name.
>
> Bryan,
>
> Spec says tab has presentational true. Table is not a required owned
> element or required context role for tab. So, the table should disappear
> and the code you provided should use the text node of the table to
> calculate the name ... that is what the spec says.
>
> Matt
>
> -----Original Message-----
> From: Bryan Garaventa [mailto:*bryan.garaventa@ssbbartgroup.com*
> <bryan.garaventa@ssbbartgroup.com>]
> Sent: Thursday, May 18, 2017 11:16 AM
> To: James Nurthen <*james.nurthen@oracle.com*
> <james.nurthen@oracle.com>>; 'ARIA Working Group'
> <*public-aria@w3.org* <public-aria@w3.org>>; 'Matt King' <
> *a11ythinker@gmail.com* <a11ythinker@gmail.com>>;
> *aleventhal@google.com* <aleventhal@google.com>; 'Dominic Mazzoni' <
> *dmazzoni@google.com* <dmazzoni@google.com>>; 'Marco Zehe'
> <*marco.zehe@gmail.com* <marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <
> *richschwer@gmail.com* <richschwer@gmail.com>>; 'david bolter' <
> *david.bolter@gmail.com* <david.bolter@gmail.com>>; 'Alexander Surkov'
> <*asurkov@mozilla.com* <asurkov@mozilla.com>>; 'James Craig' <
> *jcraig@apple.com* <jcraig@apple.com>>
> Subject: RE: Important concerns with naming calculation 'name from
> content'
> not being included in parent role accessible name.
>
> In theory yes, but where does it say in the spec this is required?
>
> This is a boiled down version of something that was used in one of our
> client websites that has been accessible for 3 years, but now is broken in
> Firefox because of this change.
>
> We should not be breaking accessibility as we go forward.
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> *bryan.garaventa@ssbbartgroup.com* <bryan.garaventa@ssbbartgroup.com>
> *415.624.2709* <(415)%20624-2709> (o)
> *www.SSBBartGroup.com* <http://www.ssbbartgroup.com/>
>
> -----Original Message-----
> From: James Nurthen [mailto:*james.nurthen@oracle.com*
> <james.nurthen@oracle.com>]
> Sent: Thursday, May 18, 2017 11:12 AM
> To: Bryan Garaventa <*bryan.garaventa@ssbbartgroup.com*
> <bryan.garaventa@ssbbartgroup.com>>; 'ARIA Working Group'
> <*public-aria@w3.org* <public-aria@w3.org>>; 'Matt King' <
> *a11ythinker@gmail.com* <a11ythinker@gmail.com>>;
> *aleventhal@google.com* <aleventhal@google.com>; 'Dominic Mazzoni' <
> *dmazzoni@google.com* <dmazzoni@google.com>>; 'Marco Zehe'
> <*marco.zehe@gmail.com* <marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <
> *richschwer@gmail.com* <richschwer@gmail.com>>; 'david bolter' <
> *david.bolter@gmail.com* <david.bolter@gmail.com>>; 'Alexander Surkov'
> <*asurkov@mozilla.com* <asurkov@mozilla.com>>; 'James Craig' <
> *jcraig@apple.com* <jcraig@apple.com>>
> Subject: RE: Important concerns with naming calculation 'name from
> content'
> not being included in parent role accessible name.
>
> As this is a table for layout
> - it should have
> role=presentation on it. This
> would then work wouldn't it?
> Regards,
> james
>
> -----Original Message-----
> From: Bryan Garaventa
> [mailto:*bryan.garaventa@ssbbar* <bryan.garaventa@ssbbar>
> *tgroup.com* <http://tgroup.com/>]
> Sent: Thursday, May 18, 2017
> 11:08 AM
> To: ARIA Working Group
> <*public-aria@w3.org* <public-aria@w3.org>>; Matt
> King <*a11ythinker@gmail.com* <a11ythinker@gmail.com>>;
> *aleventhal@google.com* <aleventhal@google.com>; Dominic
> Mazzoni <*dmazzoni@google.com* <dmazzoni@google.com>>;
> Marco Zehe
> <*marco.zehe@gmail.com* <marco.zehe@gmail.com>>; Rich
> Schwerdtfeger
> <*richschwer@gmail.com* <richschwer@gmail.com>>; david
> bolter
> <*david.bolter@gmail.com* <david.bolter@gmail.com>>;
> Alexander Surkov
> <*asurkov@mozilla.com* <asurkov@mozilla.com>>; James
> Craig <*jcraig@apple.com* <jcraig@apple.com>>
> Subject: Important concerns
> with naming calculation 'name
> from content' not being
> included in parent role
> accessible name.
>
> Hi,
> As most of us spoke of this
> last Monday in the APG call, I
> wanted to raise important
> concerns about the
> interpretation of the naming
> calculation, that specific
> roles that do not include
> 'name from content' are not
> being included in the parent
> role accessible name
> calculation.
>
> It was pointed out that this
> change is already included in
> Firefox, and I have built a
> sample that demonstrates why
> this global interpretation is
> dangerous. The following
> markup structure is now
> totally inaccessible in
> Firefox as a result of this
> change.
>
> <div tabindex="0" role="tab">
> <table>
> <tr>
> <td>
> Inbox </td>
> <td>
> (23) </td>
> </tr>
> </table>
> </div>
>
> Such a global interpretation
> would not just apply to all
> explicitly applied roles but
> to all implicitly mapped ones
> as well, and it is impossible
> to predict how and in what
> order all developers will need
> to apply ARIA roles in order
> to ensure accessibility in the
> future and that doesn't take
> into account what people are
> already doing right now.
>
> Aaron, can you please include
> the markup example here that
> you spoke of to demonstrate
> why this is a needed globally
> applied interpretation?
>
> Thanks,
> Bryan
>
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> bryan.garaventa@ssbbartgroup.c
> om
> *415.624.2709* <(415)%20624-2709> (o)
> *www.SSBBartGroup.com* <http://www.ssbbartgroup.com/>
>
>
>
>
>
>
>
>
>
>
Attachments
- image/gif attachment: graycol.gif
Received on Wednesday, 24 May 2017 14:35:18 UTC