RE: Important concerns with naming calculation 'name from content' not being included in parent role accessible name.

Since I didn't get a reply, I took a stab at mapping all of these things below. It would be good if we could all reach agreement about this to understand what affects what in the naming calculation.

List#1 includes all ARIA roles and HTML5 tags that include name from content automatically.
List#2 includes all ARIA roles and HTML tags that do not provide name from content.
List#3 includes all ARIA roles and HTML tags from list#2 that conditionally provide name from content if focusable or when embedded within an ARIA role or HTML tag found in list#1.

> 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

If I understand correctly, the following ARIA roles will always include name from content, including all child elements regardless what their role or implicit role is:

ARIA Roles:
link, button, checkbox, option, radio, switch, tab, treeitem,
menuitem, menuitemcheckbox, menuitemradio,
cell, columnheader, rowheader,
tooltip, heading

This maps to all of the following HTML5 elements that map to the same implicit ARIA roles, regardless that some don't allow child elements:
Reference: http://www.w3.org/TR/html-aria/


HTML 5 elements plus implicit ARIA role mappings:
a + href, area + href = role=link
button, summary, input + type=button|image|reset|submit = role=button
h1 to h6 = role=heading
input + type=checkbox = role=checkbox
input + type=radio = role=radio
menuitem + type=command = role=menuitem
menuitem + type=checkbox = role=menuitemcheckbox
menuitem + type=radio = role=menuitemradio
option = role=option
td = role=cell
th = role=columnheader or role=rowheader

I am unclear which ARIA roles and HTML elements the following refer to: disclosuretriangle, linebreak, menulistoption, and statictext.

> 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

So the following ARIA roles will never include name from content regardless which ARIA roles or implicit child elements are present within it.

ARIA Roles:
application,
alert, log, marquee, status, timer,
alertdialog, dialog,
banner, complementary, contentinfo, form, main, navigation, region, search,
term, definition,
article, directory, list, document, feed, figure, group, img, math, note,
table, toolbar,
menu, menubar,
combobox, grid, listbox, radiogroup, textbox, searchbox, spinbutton,
scrollbar, slider,
tablist, tabpanel,
tree, treegrid,
separator,
rowgroup, row

ARIA role=list appears to be missing from your list which goes with role=directory. Also role=separator appears to be missing as well, so too is role=textbox, role=rowgroup, and role=row.

HTML 5 elements plus implicit ARIA role mappings:
article = role=article
aside = role=complementary
body = role=document
select, datalist = role=listbox
dd = role=definition
details, optgroup = role=group
dialog = role=dialog
dl, ul, ol = role=list
figure = role=figure
footer = role=contentinfo
form = role=form
header = role=banner
hr = role=separator
img = role=img
textarea = role=textbox
input + type=text|email|tel|url (with no list attribute) = role=textbox
input + type=text|search|tel|url|email (with list attribute) = role=combobox
input + type=number = role=spinbutton
input + type=range = role=slider
input + type=search (with no list attribute) = role=searchbox
main = role=main
math = role=math
menu + type=context = role=menu
nav = role=navigation
output = role=status
section = role=region
table = role=table
thead, tbody, tfoot = role=rowgroup
tr = role=row

FYI, there is a bug in the implicit role mappings page, where dt should map to role=term and not role=listitem, since dd maps to role=definition.

You have others in your list that I don't recognize as well, so please add those ARIA roles and HTML elements here if missing as well.

> 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.

So the following ARIA roles from list#2 will conditionally allow name from content when focusable or when queried as part of a parent role from list#1 above.

(I've included all of the ARIA roles that seem to make sense for doing this where they appear to be missing in your list.)

ARIA Roles:
term, definition,
directory, list,
group, note, status,
table, rowgroup, row,
contentinfo

HTML 5 elements plus implicit ARIA role mappings:
dl, ul, ol = role=list
dd = role=definition
details = role=group
footer = role=contentinfo
output = role=status
table = role=table
thead, tbody, tfoot = role=rowgroup
tr = role=row

Included footer and role=contentinfo because this was in your original list, but I'm not sure how much it makes sense to allow this within any of the explicit or implicit roles in list#1. Thoughts?

Also, I'm not sure what the other items in your list refer to, so please add which roles these refer to as well as the HTML elements that these map to.

Does this match what you had in mind?




Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Monday, May 29, 2017 11:33 PM
To: Aaron Leventhal <aleventhal@google.com>; Ann Abbott <aabbott@us.ibm.com>
Cc: Matt King <a11ythinker@gmail.com>; Alexander Surkov <asurkov@mozilla.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>
Subject: RE: Important concerns with naming calculation 'name from content' not being included in parent role accessible name.

Thanks, this does help.

A couple of challenges though that still remain are understanding which ARIA roles specifically are affected, which is easy to pick out from your list, but this also applies to all relevant HTML elements that have implicit role mappings in the accessibility tree, which are still unclear. This list will be important for testing engines that need to approximate the same results when computing the naming calculation in order to return the same results as those exposed appropriately within the browsers. This is also needed to identify when bugs exist between the browsers in cases when the naming calculation is incorrectly computed.

If you already have a list of all of these implicit HTML elements providing this would be helpful, otherwise I can take a stab at generating this if you wish myself. I will be travelling all this week but will be back next week and can start this then if you like.

All the best,
Bryan



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: Aaron Leventhal [mailto:aleventhal@google.com]
Sent: Wednesday, May 24, 2017 7:34 AM
To: Ann Abbott <aabbott@us.ibm.com<mailto:aabbott@us.ibm.com>>
Cc: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; Alexander Surkov <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; david bolter <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>; Dominic Mazzoni <dmazzoni@google.com<mailto:dmazzoni@google.com>>; James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>; Marco Zehe <marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>; Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>
Subject: Re: Important concerns with naming calculation 'name from content' not being included in parent role accessible name.

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<mailto: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<tel:(512)%20286-5002>
aabbott@us.ibm.com<mailto:aabbott@us.ibm.com>

“It always seems impossible until it's done.”

― Nelson Mandela

18 July 1918 – 5 December 2013



[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<mailto:aleventhal@google.com>>
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>, Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>, James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>, ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>, Dominic Mazzoni <dmazzoni@google.com<mailto:dmazzoni@google.com>>, Marco Zehe <marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>, Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>, david bolter <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>, Alexander Surkov <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>, James Craig <jcraig@apple.com<mailto: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<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709<tel:(415)%20624-2709> (o)
www.SSBBartGroup.com<http://www.ssbbartgroup.com/>

-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>]
Sent: Monday, May 22, 2017 3:23 PM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; 'James Nurthen' <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>; aleventhal@google.com<mailto:aleventhal@google.com>; 'Dominic Mazzoni' <dmazzoni@google.com<mailto:dmazzoni@google.com>>; 'Marco Zehe' <marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>; 'david bolter' <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>; 'Alexander Surkov' <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; 'James Craig' <jcraig@apple.com<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709<tel:(415)%20624-2709> (o)
www.SSBBartGroup.com<http://www.ssbbartgroup.com/>

-----Original Message-----
From: Matt King [mailto:a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>]
Sent: Thursday, May 18, 2017 3:52 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; 'James Nurthen' <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>; aleventhal@google.com<mailto:aleventhal@google.com>; 'Dominic Mazzoni' <dmazzoni@google.com<mailto:dmazzoni@google.com>>; 'Marco Zehe' <marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>; 'david bolter' <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>; 'Alexander Surkov' <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; 'James Craig' <jcraig@apple.com<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>]
Sent: Thursday, May 18, 2017 1:43 PM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; 'James Nurthen'
<james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>; aleventhal@google.com<mailto:aleventhal@google.com>; 'Dominic Mazzoni' <dmazzoni@google.com<mailto:dmazzoni@google.com>>; 'Marco Zehe'
<marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>; 'david bolter' <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>; 'Alexander Surkov' <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; 'James Craig' <jcraig@apple.com<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709<tel:(415)%20624-2709> (o)
www.SSBBartGroup.com<http://www.ssbbartgroup.com/>

-----Original Message-----
From: Matt King [mailto:a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>]
Sent: Thursday, May 18, 2017 12:20 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; 'James Nurthen'
<james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>; aleventhal@google.com<mailto:aleventhal@google.com>; 'Dominic Mazzoni' <dmazzoni@google.com<mailto:dmazzoni@google.com>>; 'Marco Zehe'
<marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>; 'david bolter' <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>; 'Alexander Surkov' <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; 'James Craig' <jcraig@apple.com<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>]
Sent: Thursday, May 18, 2017 11:16 AM
To: James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; 'ARIA Working Group'
<public-aria@w3.org<mailto:public-aria@w3.org>>; 'Matt King' <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; aleventhal@google.com<mailto:aleventhal@google.com>; 'Dominic Mazzoni' <dmazzoni@google.com<mailto:dmazzoni@google.com>>; 'Marco Zehe'
<marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>; 'david bolter' <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>; 'Alexander Surkov' <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; 'James Craig' <jcraig@apple.com<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709<tel:(415)%20624-2709> (o)
www.SSBBartGroup.com<http://www.ssbbartgroup.com/>

-----Original Message-----
From: James Nurthen [mailto:james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>]
Sent: Thursday, May 18, 2017 11:12 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; 'ARIA Working Group'
<public-aria@w3.org<mailto:public-aria@w3.org>>; 'Matt King' <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; aleventhal@google.com<mailto:aleventhal@google.com>; 'Dominic Mazzoni' <dmazzoni@google.com<mailto:dmazzoni@google.com>>; 'Marco Zehe'
<marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; 'Rich Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>; 'david bolter' <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>; 'Alexander Surkov' <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; 'James Craig' <jcraig@apple.com<mailto: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<mailto:bryan.garaventa@ssbbar>
tgroup.com<http://tgroup.com/>]
Sent: Thursday, May 18, 2017
11:08 AM
To: ARIA Working Group
<public-aria@w3.org<mailto:public-aria@w3.org>>; Matt
King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>;
aleventhal@google.com<mailto:aleventhal@google.com>; Dominic
Mazzoni <dmazzoni@google.com<mailto:dmazzoni@google.com>>;
Marco Zehe
<marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; Rich
Schwerdtfeger
<richschwer@gmail.com<mailto:richschwer@gmail.com>>; david
bolter
<david.bolter@gmail.com<mailto:david.bolter@gmail.com>>;
Alexander Surkov
<asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; James
Craig <jcraig@apple.com<mailto: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<mailto:bryan.garaventa@ssbbartgroup.c>
om
415.624.2709<tel:(415)%20624-2709> (o)
www.SSBBartGroup.com<http://www.ssbbartgroup.com/>