Revising what ARIA attributes should be considered global

[scottaohara]

Per mention in the WG call today, and spurred by the discussions started with #990, I've created the following break down for review of the attributes I believe should remain global, and those that should become either prohibited on roles where they don't make sense, or should be removed from being global attributes all together.

The following has been worded under the assumption the attributes would be removed from being global:

Attributes to remain global

• aria-atomic
• aria-busy (state)
• aria-current (state)
• aria-dropeffect - "deprecated"
• aria-flowto
• aria-grabbed (state) - "deprecated"
• aria-hidden (state)
• aria-live
• aria-owns
• aria-relevant
• aria-roledescription

Attributes to remain global, but prohibited

Per other work already happening for role=generic and accName, aria-label and aria-labelledby have consensus of staying global, but should be noted as prohibited due to wanting to advice against naming certain roles.

• aria-label
• aria-labelledby

I'd also submit that if a role shouldn't be named, it also likely shouldn't have a description associated with it...

• aria-describedby
• aria-details

Undecided

aria-keyshortcuts
I'm not exactly sure what to do with this one. Is there actual value in allowing keyboard shortcuts for non-interactive elements? I can't think of a reason, but maybe someone else?

Attributes to reallocate to specific roles

Pending further discussion, especially regarding the roles that are listed with a "(?)", the following attributes should not be global, or should be noted as prohibited on all applicable roles where they would not be expected.

aria-disabled should be allowed on:

• Widget Container Roles
• Widget roles excluding:
  • link
  • meter
  • progressbar
  • scrollbar
  • separator
  • tabpanel

Discussion point

aria-disabled could be allowed on the following Document Structure roles as well:

• application
• group
• toolbar

Doing so would allow for parity with HTML's allowance of <fieldset disabled>. Though allowing on these could also be more trouble than its worth. Really interested to hear what others think.

aria-errormessage and aria-invalid should be allowed on:

• checkbox
• combobox
• listbox
• tree
• gridcell
• radiogroup
• searchbox
• slider
• switch
• textbox

aria-controls should be allowed on:

• button
• checkbox
• link
• menuitem (?)
• menuitemcheckbox (?)
• menuitemradio (?)
• option (?)
• radio
• scrollbar
• searchbox
• slider
• spinbutton
• switch
• tab
• textbox (?)
• treeitem (?)

Note, #995 may mean aria-controls should remain global until a larger discussion on if any redefinition of the attribute should take place so that AT will be more inclined implement it / not ignore it.

aria-haspopup should be allowed on:

• button
• combobox
• gridcell (?)
• menuitem
• searchbox
• slider (?) - datalist is allowed on HTML's input but treated differently
• textbox
• treeitem (?)

(edit) Final note:

Whatever is decided here, I'd imagine a good path forward would be to not necessarily act on this as a single issue, but to create sub-issues for any reallocation. Then make PRs on those sub-tasks individually, instead of tackling this all at once.

[jnurthen]

I think aria-invalid & aria-errormessage are missing some.
I would add

• tree
• gridcell
• radiogroup (remove radio as this makes no sense)

[scottaohara]

updated the list to add those in. from here on out i won't edit the original list, just figured it made sense since discussion hadn't picked up yet.

[scottaohara]

Also for consideration per today's call, aria-roledescription should likely remain global, but prohibited from role=generic

[carmacleod]

Possibly related discussion regarding aria-controls in APG: w3c/aria-practices#805

[scottaohara]

note: pending further discussion on aria-haspopup, tab should have been in the listing of role allowances.

I am curious as to the mechanism that would invoke the popup on a tab, outside of potentially having to note to press a particular key to reveal the popup widget. Not sure how that would translate to touch devices right now.

[carmacleod]

Probably need to allow AllTheThings on role="application"? In case someone uses it to create a non-standard widget?

[scottaohara]

i'd submit they're not necessary on the application itself, but may be on the focusable elements that the application contains.

[jnurthen]

@scottaohara application is pretty much any unknown widget. I don't see why it may not have any of these attributes.

[scottaohara]

fair point i suppose. i just typically think of it as a wrapper to the focusable elements within being it's a subclass of a structure role

A structure containing one or more focusable elements requiring user input, such as keyboard or gesture events, that do not follow a standard interaction pattern supported by a widget role.

that said, with aria-roledescription i guess why not allow the application to be the focusable element itself and let it / its child content be affected by the user input/gestures/what-have-you