aria-practices
aria-practices copied to clipboard
w3c
Discuss removing recommendation in menubutton pattern to add/remove aria-expanded="true
For menu buttons and menu bars there is a different treatment of aria-expanded. For the menu button, there is no aria-expanded on page load and then only added when it's open. So it doesn't toggle between true and false ... instead the entire attribute is added and removed. This apparently is to reduce chattiness
This process of adding and removing the entire attribute on expand/collapse has spotty support in JAWS, VO and NVDA. It is also tough to explain to devs... They will ask why add and remove the entire attribute when there is true/false to toggle in aria-expanded.
On the other hand, the navigation menu has aria-expanded=false on page load. So the two examples are inconsistent.
It seems like we could have a more elegant and consistent solution for aria-expanded on menus.
Maybe I should file a but against aria-haspop over on the aria 1.1 to allow an extra attribute to swap out for menus so it doesn't have the redundancy but doesn't require the clunky adding and removing the full attribute to show expanded state....
Or maybe AT should not announce collapsed when an aria-popup is present??
Anyway, adding removing the entire attribute and value on show/hide smells like a hack to address AT issues, or to overcome a limitation of wai-aria.
This is the current pertinent language in the button example:
"Added when the menu is open.Indicates that the menu is displayed and that activating the menu button closes the menu. The aria-expanded attribute is removed when the menu is closed. Included to support touch devices where screen reader users can touch the menu button when the menu is displayed. Keyboard users cannot focus the menu button when the menu is open.
@patrickhlauke, was filling in issue and hit enter... its there now.
@DavidMacDonald, not including aria-expanded when the menu is not displayed is optional behavior. The way we worded this in the pattern is:
When the menu is displayed, the element with role button has aria-expanded set to true. When the menu is hidden, it is recommended that aria-expanded is not present. If aria-expanded is specified when the menu is hidden, it is set to false.
If we updated the states and properties table on the menubutton example pages to include similar language, would that be sufficient?
I don't see a need to change the ARIA spec.
It just seems buggy to be recommending to add and remove the entire attribute instead of toggling it true/false. What about lobbying the AT to ignore aria-expanded="false" when aria-haspopup is present.
If add/remove is preferred, a proper boolean attribute is The Right Thing. But AFAIK wai-aria has no true boolean attributes. The add/remove mechanism of true boolean attributes are already a source of many cognitive errors (because someBooleanAttribute="false" evaluates -counter-intuitively- the same as someBooleanAttribute="true")
IMO an attribute with possible values true/false should have those values set explicitly, rather than removing it to suggest 'false'. Inconsistencies are inevitable if an attribute becomes optional in a some states and not others.
Reducing doubt amongst those consulting the examples should override vague concerns about 'chattiness'. The 'chattiness' problem is for the AT vendors to handle (if indeed it is a problem at all).
But... consistency first. Whichever is the preferred mechanism, let's do it the same way in all examples and recommendations - and if we're going with add/remove, perhaps provide a note about why this might be counter-intuitive. Otherwise it will become a FAQ.
The ARIA Authoring Practices (APG) Task Force just discussed Issue 697 about aria-expanded=false on menu buttons.
The full IRC log of that discussion
<jugglinmike> Topic: Issue 697 about aria-expanded=false on menu buttons<jugglinmike> github: https://github.com/w3c/aria-practices/issues/697
<jugglinmike> s/a patch/a patch for issue gh-1611/
<jugglinmike> Matt_King: People were so confused by this that they were suggesting a new property in gh-697
<jugglinmike> Matt_King: I have written a pull request which removes the recommendation
<jugglinmike> Matt_King: If we go that route, we will need to change three menu button examples
<jugglinmike> Bryan_Garaventa: we originally proposed this because on some devices (E.g. those based on touch), you cannot perceive menu hierarchy
<jugglinmike> Bryan_Garaventa: That leads me to two questions
<jugglinmike> Bryan_Garaventa: How do you identify hierarchy if you take it out?
<jugglinmike> Matt_King: Today, our menu buttons don't have "aria-expanded=false" when they are collapsed
<jugglinmike> Bryan_Garaventa: Oh, so this isn't about removing the attribute
<jugglinmike> Matt_King: No, so it's about applying it consistently
<siri> +1
<jugglinmike> Bryan_Garaventa: Ah! Yes, I would recommend consistency. Especially for those using touch screen devices
<jugglinmike> Matt_King: The clarity of knowing that it is collapsed is helpful
<dmontalvo> +1 to adding aria-expanded="false" when collapsed for clarity.
<jugglinmike> siri: I support this, as well
<jugglinmike> Matt_King: Sounds like we have a lot of votes here, all in favor!
<jugglinmike> Matt_King: There are three menu button examples that would need to change
<jugglinmike> Matt_King: I have already submitted a pull request for the pattern
<jugglinmike> Matt_King: I think this should be two separate pull requests. I think the code changes should be done in a separate pull request
<jugglinmike> Zakim, end the meeting
