accname
accname copied to clipboard
w3c
ARIA Spec could be more flexible when elements with "nameFrom:author" are left unlabeled by the author
I received the following bug report from a member of my team.
Summary: Web AX, VoiceOver: When browsing list of articles using VO Articles rotor on [site redacted], VO announces each item as "Article" without speaking headline
Steps To Reproduce:
- Turn on VoiceOver.
- Open Safari and browse to [site redacted].
- Press VO-U to bring up rotors.
- Press VO-Right arrow repeatedly to select “Articles” rotor.
- Explore rotor items by pressing VO-Down arrow.
Results: When using VO’s Articles rotor, VO does show all the articles presented on [site redacted], but only speaks each item as “Article” without providing any additional info, such as the article’s headline. For better clarity, VO should speak some additional information here.
Upon closer inspection, the articles are not labeled but they all have a heading in close proximity to the start of the article element. For the sake of the user, we could probably work around this web page error heuristically in either WebKit or VoiceOver, but the ARIA spec appears to explicitly discourage this.
The ARIA spec could add some language explicitly allowing user agents to heuristically determine the label for unlabeled elements whose label has not been set by the author. In this case, the most logical choice would be to find the first heading in the article.
Perhaps: "User Agents MAY use heuristics to determine the label of an unlabeled element, if the role characteristics include nameFrom: author. For example, browsers may set the label of an unlabeled dialog to be the first heading in that dialog."
The problem identified in the bug report makes sense as something we probably want to solve. But I'm not sure I agree with the solution described. Any time user agents MAY do something which changes what ATs will present, we decrease the likelihood of interoperability. Doubly so when the thing user agents MAY do is use an unspecified heuristic. I think we potentially would want one of the following instead:
- Authors MUST name their articles/dialogs/whatever, or
- User agents MUST expose articles/dialogs/whatever with headings in the same way they would had aria-labelledby been used to point to that heading, or
- Something in AccName causing this calculation to automatically occur
This would be great for articles and dialogs (possibly others, like maybe even most landmarks) but need to be careful with <section> element, because giving a section a name changes it into a landmark, which really needs to be an intentional decision by the author, and not just a side effect of putting a heading in a section.
I think we would need the "Something in AccName" option (which of course is a "User Agents MUST" anyhow :) ). It's probably element-specific enough that it should go in HTML AAM Name & Description.
There could be an option for an ARIA role like accname from first heading, similar to the checkbox and other roles has accname from content. It would help strengthen the need for proper use of headings in a document.
+1 to an AccName update for first heading inside of elements with certain roles. Probably not group but article and dialog are obvious wins.
The reason for the flexibility though is other common cases. For example, even if there is no heading in an article, the first non-linked line of text is more useful that speaking nothing. Maybe not in the case of a dialog, where you're guaranteed to read the contents, but in the case of an article, users want to hop article to article, an have something—anything—spoken. This inferred "label" would be the cue to move on to the next, or stop and read.
If there's a clean choice for label or heading, great. AccName should be updated to account for any logical pattern authors use.
But the reality of the Web is messy, and a user agent's primary responsibility is to make the user experience the best as possible, regardless of whether the markup conforms to the choices outlined in the AccName. In those cases, heuristic fallbacks (even those with interoperability issues) are a valid solution.
If there's a clean choice for label or heading, great. AccName should be updated to account for any logical pattern authors use.
+1
But the reality of the Web is messy, and a user agent's primary responsibility is to make the user experience the best as possible, regardless of whether the markup conforms to the choices outlined in the AccName. In those cases, heuristic fallbacks (even those with interoperability issues) are a valid solution.
Fair enough. But let's avoid things like you suggested in your opening report, namely "User Agents MAY use heuristics..." I'm a big fan of User Agents SHOULD/MUST followed by very concrete expectations. Let's figure out how to fix the problem you described in an interoperable fashion. Please. :)
Perhaps the solution could be to add another nameFrom value: author, contents, and a new contentLabels. article would then be nameFrom: author, contentLabels and the specifics of what contentLabels allows could be worked out in the ARIA spec or AccName.
@cookiecrook
Perhaps the solution could be to add another
nameFromvalue ...
Cool - I think that's what @jongund said, also. :)
It does seem like a simple way to spec this idea (although I would go with the singular contentLabel rather than the plural).
Aside: we may be adding nameFrom: unsupported as well, and we briefly discussed nameFrom: labelRole to indicate which roles can be labelled by the new label role.
Hi, for the record, I'm not in favor of including a guesswork qualifier in the AccName. If you do this for one thing, lazy devs will want this for everything. Also the processing overhead for doing this is extensive, and there is no way to phraze this in a non-HTML specific manner. And even if all of these things are done anyway, it still won't be reliable.
We already have explicit labelling mechanisms, and devs need to learn how to use them properly.
The ARIA Working Group just discussed Flexibility of namefrom.
The full IRC log of that discussion
<jamesn> topic: Flexibility of namefrom<MarkMcCarthy> jamesn: this is what JamesCraig wanted to discuss
<jamesn> github: https://github.com/w3c/aria/issues/899
<MarkMcCarthy> JamesCraig: basically, on a news site, every article kept saying "article" even though everything looked right
<MarkMcCarthy> ... so maybe we need more flexibility for inferred labels
<MarkMcCarthy> ... in particular <dialog> and <article>
<MarkMcCarthy> ... might not want to pick the first line, but if there's a first (unique) heading, that could be inferred
<Stefan> q+
<MarkMcCarthy> ... in <dialog>, it might be useful to be even more flexible. if there's a logical first line of text, we could infer it's the label
<MarkMcCarthy> jamesn: joanie is very against any heuristic fallback, so if we can define and glean general support, that's fine. but we have to define correctly
<MarkMcCarthy> ... need definitive guidance. gut feel is that it'd be the first child heading
<MarkMcCarthy> ... might not work with everything, but as a screen reader dev. you're free to do as you wish
<MarkMcCarthy> mck: it seems to me like that's too loose, because if you have a bunch of descendants, that might not be a good heuristic
<MarkMcCarthy> ... i don't know how you'd limit it
<MarkMcCarthy> ... inference is tricky and kinda risky
<jamesn> q+
<MarkMcCarthy> ... risk of having wrong label on these... for a dialog not huge, but for article could be a lot
<MarkMcCarthy> JamesCraig: I think this would be lower in priority than title. only if there was no label conveyed would this apply
<MarkMcCarthy> ack Stefan
<jamesn> ack Ste
<MarkMcCarthy> Stefan: I'm in Joanie's camp, this could have lots of implementations and could be complex
<MarkMcCarthy> ... some screen readers may behave, some may not
<Stefan> q-
<MarkMcCarthy> ... it's a good idea, but it might often get corrupted
<jamesn> ack me
<MarkMcCarthy> jamesn: i propose that someone who's interest, collect data on what might work for articles etc. and determine if we can come up with a programmatic, 90% correct idea
<MarkMcCarthy> mck: I don't know if I'd support that, it's too easy to collect potentially junk data
<MarkMcCarthy> mck: I'm agreeing, if its an absolute fallback esp. if the experience isn't optimlly coded
<MarkMcCarthy> ... some people accuse Vispero for not waiting on data, others accusing NVDA of the opposite - there's lots of perspectives
<MarkMcCarthy> ... idea that we're building in inference is an interesting proposal
<MarkMcCarthy> ... we should do so cautiously. data might not help
<MarkMcCarthy> q+ JamesCraig
<MarkMcCarthy> q+ Bryan
<MarkMcCarthy> ack jame
<MarkMcCarthy> JamesCraig: the context is prioritizing needs of users over all
<MarkMcCarthy> ... if specification is too rigid, it can be challenging to make things work for users
<MarkMcCarthy> ... similar to this is browsers and layout vs. data tables
<MarkMcCarthy> ... even if something doesn't work, i might need to do something anyway. I wanted to, if possible, find a great solution for user agents and users even if spec and authors are wonky
<MarkMcCarthy> ack Bryan
<jamesn> q+
<MarkMcCarthy> Bryan: i agree, but I am concerned about if we open the door to this, we might see more bad coding practices
<MarkMcCarthy> ... if you go to devs and ask "do you want to label things or have it done automatically?" obviously they'd say yes
<MarkMcCarthy> ... we don't want to promote bad practices
<MarkMcCarthy> mck: +1 to spirit of JamesCraig's intention
<MarkMcCarthy> ... ideally, we want to prevent the automatic thing
<pkra> bye
<MarkMcCarthy> jamesn: this was a great discussion. JamesC, it sounds like you need articles to have an ACCNAME?
<MarkMcCarthy> JamesCraig: I don't know if I'd use require, but if we land on it with no label, we just read role description
<MarkMcCarthy> ... particularly with the VO rotor
<MarkMcCarthy> ... i'm trying to make that UX better
<MarkMcCarthy> jamesn: could you read the first line if nothing defined?
<MarkMcCarthy> JamesCraig: we'd have to look into things a little more
<MarkMcCarthy> ... there is a risk of weird worseness, but if 90% is better, that's a win
<MarkMcCarthy> jamesn: and author can override with a label
<MarkMcCarthy> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2019/02/14-aria-minutes.html MarkMcCarthy
From a HTML-AAM perspective there are already a number of elements that get their accessible name from child elements (when present caption names table, figcaption names figure). This could be extended to other elements with a h1-h6 element as the source, for appropriate elements.
If so, I'd like that computation extension being persisted in HTML-AAM, too. Preferably with a list of containers and children where this implicit mapping applies.
We have just added encapsulation and legend accessible name computation techniques, so it seems logical to name the heading technique heading.
A proposed definition for heading:
'heading': name comes from the text value of the first descendant element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [ACCNAME-1.1]
Proposed roles the heading technique could be used with:
alertdialogarticle, see HTML5 spec for articlecomplementarydialogformnavigationtabpanel
Issues
- Need to look at nested roles, for example you do not want nested elements with role
articleto have the same accessible name
Trying to summarize consensus at today's face-to-face:
-
Looking at the nearest descendant heading seems like a good idea potentially. We would need to be sure we weren't descending into other, nested articles. Some research is called for.
-
We had some discussion about putting something in the remediation section of the spec, but this isn't exactly remediation because name is not required on articles.
Regarding doing the research, a tool was presented that might be helpful in searching for different uses. A couple of examples of other searches:
- https://discuss.httparchive.org/t/usage-of-aria-attributes/778
- https://discuss.httparchive.org/t/pages-with-role-text/809
How would this work with examples 1, 4, and 5 in https://w3c.github.io/html/common-idioms-without-dedicated-elements.html#subheadings-subtitles-alternative-titles-and-taglines ?
Presumably the header would be labelled by the heading tag but if that header is contained in an article, the author's intent would be to label the article, not its header. aria-labelledby could be used to make that explicit but then the article and the header in the article have the same label. Maybe it would suffice to not use a heading as an implicit label if it's explicitly labeling another element?
a header within an article would no longer map to a role=banner, since the header wouldn't be scoped to body. So the heading could still map to its parent article.
This actually seems like it could be a good first check to make sure the author intended heading is provided to the parent article.
This morning we discussed drafting a PR on accname to resolve this, but currently it's in the aria tracker. What's the best way to associate this issue with that project? Should it be moved/cloned to accname? Should I reference it from a PR in accname? Looking for guidance from the current editors.
Removing my assignment because I will not be able to address this in the 1.3 Milestone.
I can't promise a timeline, but I'll take assignment again to draft some straw man text before we deep dive again on this. (If someone else wants to take assignment to draft the PR though, I approve.)
We will need to also update HTML AAM with a specific entry for article in the accName/description section.
Based on how we have things setup there, I'd (presently) assume HTML AAM's rough text could look something like the following:
- If the
articleelement has an has anaria-labelor anaria-labelledbyattribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings. - If the accessible name is still empty, then: if the
articleelement has a descendant heading element, then use the subtree of the first such element so long as that heading element is not itself a descendant, (or owned by) anotherarticleelement. :: additional wording here to look for the next available heading element if the first heading would not be usable??? :: - If the accessible name is still empty, then: if the
articleelement has atitleattribute, then use that attribute. - Otherwise, there is no accessible name.
@cookiecrook is the above inline with current thinking on this? This rough draft is purely based on the discussion that was available in this thread.
Sorry I missed this reply question. I would expect the "nameFrom: heading" stuff to be added to Core-AAM (which item 2 could link to) before you should address it in HTML-AAM.
Some updates from the WG F2F meeting captured in https://github.com/w3c/aria/pull/1018/
agenda+ because this issue came up again in: https://github.com/w3c/accname/issues/226
@accdc can you find the related issue or PR with your proposed changes?
The related issue is: https://github.com/w3c/aria/issues/1821
Proposals are being discussed there.