ISSUE-587: Consider allowing the aria-selected state on any focusable element, or add a new attr like aria-active or aria-current
aria-selected on more elements
Consider allowing the aria-selected state on any focusable element, or add a new attr like aria-active or aria-current
- State:
- CLOSED
- Product:
- ARIA 1.1 Core Mapping Specification
- Raised by:
- Steve Faulkner
- Opened on:
- 2013-06-20
- Description:
- From Steve Faulker via:
http://lists.w3.org/Archives/Public/wai-xtech/2012Jul/0006.html
> Allow the aria-selected state on any focusable element
>
> http://www.w3.org/WAI/PF/aria/states_and_properties#aria-selected
>
> Rationale
>
> quite often on web sites and web apps it would be useful to provide an
> indication of current selection, for example on a step in a process, but it
> is not appropriate or practical to use the currently defined roles that
> aria-selected is allowed on.
Note: Keep this in context of ACTION-1073. - Related Actions Items:
ACTION-1442 on Léonie Watson to Create spec. text for aria-currentfor="IDREF" and aria-current="true/false", related to issue-587 - due 2014-10-13, closedACTION-1528 on Alexander Surkov to Bolter to investigate the proper ia2 mappings for aria-current - due 2014-11-18, closedACTION-1529 on Joseph Scheuhammer to Investigate the proper atk/at-spi mappings for aria-current - due 2014-11-18, closedACTION-1548 on Joanmarie Diggs to Write revised proposal for aria-current based on today’s meeting for issue 587 - due 2015-01-29, closedACTION-1535 on James Craig to Investigate the axapi mappings for aria-current. - due 2015-08-18, closedACTION-1527 on Joseph Scheuhammer to Investigate the proper uia mappings for aria-current - due 2015-10-01, closed- Related emails:
- No related emails
Related notes:
FWIW, I'm worried about overloading "selected" which currently implies user-selectability to mean something else on readonly or static interface elements like links. The term "selected" is already misused or overused. It's commonly confused with other similar terms like focused, activated, etc. ARIA 1.0 at least uses aria-selected consistently. If we change that, I think we'd b introducing more confusion for authors.
There is also PFWG-ISSUE-504 to consider, where where we want to change the taxonomy so that aria-selected is NOT allowed on radio buttons to avoid author confusion. Radio buttons currently inherit aria-selected from the option role and inherit aria-checked from the checkbox role, so authors frequently use aria-selected="true" on radios when they intend to use aria-checked="true".
Despite my objections to using aria-selected on *any* focusable element, I think the idea of indicating which link points to the current page is sound, and am generally supportive of adding either a new attribute, or allowing aria-selected on more roles such as link.
Linking similar thread
aria-active or overloading aria-selected (Was: Suggested ARIA state)
http://lists.w3.org/Archives/Public/public-pfwg/2014Jan/0068.html
Current thread is suggesting aria-current over aria-active.
James Craig, 24 Apr 2014, 08:00:44Cooper proposed aria-currentfor="IDREF" in today's call.
James Craig, 12 May 2014, 18:28:58rs: summarize: aria-current is boolean
rs: which would indicate current item in context
rs: aria-context take idref, in future possibly some other reference (selector, etc)
rs: would apply to container of the aria-current that it applies to
rs: may apply to other attributes
querySelector is supported in IE8+ (completes action 1443)
Cynthia Shelly, 20 May 2014, 22:53:13To be fixed in action 1442.
Richard Schwerdtfeger, 2 Jun 2014, 18:35:18moved to an implementation spec. issue as it is addressed in the ARIA Spec.
Richard Schwerdtfeger, 14 Jun 2015, 20:53:27Closing as done.
Display change log
