- From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
- Date: Thu, 29 Jun 2017 22:15:59 +0000
- To: Bryan Garaventa <bryan.garaventa@levelaccess.com>, 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>, Joanmarie Diggs <jdiggs@igalia.com>
- Message-ID: <BN6PR03MB2785BE03BFD02235F03756DAF2D20@BN6PR03MB2785.namprd03.prod.outlook.com>
As an update to my earlier message today, I've been testing the various markup using the new algorithm and it works quite well, with one exception.
The role combobox needs to be added to list3 (conditional exceptions) in order for this to work accessibly for this widget type.
I understand why you added this to list2 (never include), since this would be undesirable for future comboboxes built using the 1.1 design pattern where the focusable elements are children of role=combobox, however not providing an exception for this role results in the following issue when using the 1.0 combobox design pattern instead.
<div id="lblId" role="combobox" aria-expanded="false" tabindex="0">
Select Language
</div>
According to the new algorithm the accessible name is now "" (nothing) for this widget, which is the same issue I brought up previously about role=tab in Firefox. Since it is important not to break prior functionality, the combobox role needs to be added to list3 in order to include it as an exception when this widget role is focusable.
After this role is added, the accessible name for this markup then becomes "Select Language". I can't see any situations where this would present a conflict between the 1.0 and 1.1 design patterns because this role will still be ignored when role=combobox is not focusable as shown in the 1.1 design pattern.
I've already made this change to all of the previously mentioned GitHub projects as well as within Visual ARIA, and have pasted the revised lists below as they occur within the algorithm source code for reference.
// Always include name from content when the referenced node matches list1, as well as when child nodes match those within list3
var lst1 =
{
roles: ',link,button,checkbox,option,radio,switch,tab,treeitem,menuitem,menuitemcheckbox,menuitemradio,cell,columnheader,rowheader,tooltip,heading,',
names: ',a,button,summary,input,h1,h2,h3,h4,h5,h6,menuitem,option,td,th,'
},
// Never include name from content when current node matches list2
lst2 =
{
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,',
names: ',article,aside,body,select,datalist,dd,details,optgroup,dialog,dl,ul,ol,figure,footer,form,header,hr,img,textarea,input,main,math,menu,nav,output,section,table,thead,tbody,tfoot,tr,'
},
// As an override of list2, conditionally include name from content if current node is focusable, or if the current node matches list3 while the referenced parent node matches list1.
lst3 =
{
roles: ',combobox,term,definition,directory,list,group,note,status,table,rowgroup,row,contentinfo,',
names: ',dl,ul,ol,dd,details,output,table,thead,tbody,tfoot,tr,'
};
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com
From: Bryan Garaventa [mailto:bryan.garaventa@levelaccess.com]
Sent: Thursday, June 29, 2017 9:15 AM
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>; Joanmarie Diggs <jdiggs@igalia.com>
Subject: RE: Important concerns with naming calculation 'name from content' not being included in parent role accessible name.
Hello,
To reflect what we've been discussing here, I've updated the recursive naming calculation script within the github repo at
https://github.com/accdc/w3c-alternative-text-computation
Aaron and others, if you could please review the algorithm and see if this covers the scenarios that you brought up I would appreciate it. This will be incorporated into testing engines so it needs to be correct in a way that we all agree on.
The following code is readable and executable in full in the above repo, within the folder/file Sample JavaScript Recursion Algorithm/recursion.js
There are also test files within that can be used to demonstrate the algorithm in action which can be modified to show differing results for testing purposes. (Contributions to the repo are definitely welcome if anyone is interested.)
Here are the relevant code changes in the manner that we've been discussing.
// Always include name from content when the referenced node matches list1, as well as when child nodes match those within list3
var lst1 =
{
roles:
',link,button,checkbox,option,radio,switch,tab,treeitem,menuitem,menuitemcheckbox,menuitemradio,cell,columnheader,rowheader,tooltip,heading,',
names: ',a,button,summary,input,h1,h2,h3,h4,h5,h6,menuitem,option,td,th,'
},
// Never include name from content when current node matches list2
lst2 =
{
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,',
names:
',article,aside,body,select,datalist,dd,details,optgroup,dialog,dl,ul,ol,figure,footer,form,header,hr,img,textarea,input,main,math,menu,nav,output,section,table,thead,tbody,tfoot,tr,'
},
// As an override of list2, conditionally include name from content if current node is focusable, or if the current node matches list3 while the referenced parent node matches list1.
lst3 =
{
roles: ',term,definition,directory,list,group,note,status,table,rowgroup,row,contentinfo,',
names: ',dl,ul,ol,dd,details,output,table,thead,tbody,tfoot,tr,'
};
This naming calculation update has already been added to Visual ARIA as well, available at the same url as before.
http://whatsock.com/training/matrices/visual-aria.htm
If you notice any roles or HTML5 elements that are missing please let me know, otherwise please let me know if this works as expected.
Best wishes,
Bryan
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>
From: Bryan Garaventa
Sent: Friday, June 09, 2017 2:11 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>>; 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>>; 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.
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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<http://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<mailto:aleventhal@google.com>>; 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>>; 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.
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/>
Attachments
- image/gif attachment: image001.gif
Received on Thursday, 29 June 2017 22:16:40 UTC