Search and Top Navigation
#3525 open bug ()
Opened October 29, 2008 05:49PM UTC
Last modified October 29, 2013 12:17AM UTC
Selectable: Add ARIA semantics and keyboard handling
Reported by: | davidb | Owned by: | scottgonzalez |
---|---|---|---|
Priority: | minor | Milestone: | 2.0.0 |
Component: | ui.selectable | Version: | 1.6rc2 |
Keywords: | Cc: | michelled | |
Blocked by: | Blocking: |
Description
For accessibility, we should add an attribute to elements that are selectable. Using WAI-ARIA we can do the following:
1. If an element is selectable, specify attribute aria-selected=false
1. If an element is selectable, and selected, aria-selected=true
1. If an element is not selectable, provide no aria-selected attribute
So in codespeak something like:
this.element.addClass("ui-selectable");
would be:
this.element.addClass("ui-selectable").ariaState("selected",false);
I wonder if we should first refactor (extract-method) such that there are one or two places where selection related classes are added or removed?
Attachments (0)
Change History (9)
Changed October 29, 2008 05:50PM UTC by comment:1
description: | For accessibility, we should add an attribute to elements that are selectable. Using WAI-ARIA we can do the following: \ \ 1. If an element is selectable, specify attribute aria-selected=false \ 2. If an element is selectable, and selected, aria-selected=true \ 3. If an element is not selectable, provide no aria-selected attribute \ \ So in codespeak something like: \ {{{ \ this.element.addClass("ui-selectable"); \ }}} \ would be: \ {{{ \ this.element.addClass("ui-selectable").ariaState("selected",false); \ }}} \ \ I wonder if we should first refactor (extract-method) such that there are one or two places where selection related classes are added or removed? → For accessibility, we should add an attribute to elements that are selectable. Using WAI-ARIA we can do the following: \ \ 1. If an element is selectable, specify attribute aria-selected=false \ 1. If an element is selectable, and selected, aria-selected=true \ 1. If an element is not selectable, provide no aria-selected attribute \ \ So in codespeak something like: \ {{{ \ this.element.addClass("ui-selectable"); \ }}} \ would be: \ {{{ \ this.element.addClass("ui-selectable").ariaState("selected",false); \ }}} \ \ I wonder if we should first refactor (extract-method) such that there are one or two places where selection related classes are added or removed? |
---|
Changed December 12, 2008 02:49AM UTC by comment:2
From #3481 (duplicate):
The "Selectable" interaction might be a good place to auto-expose the following ARIA semantics: aria-selected aria-multiselectable
The aria-multiselectable = true|false would apply to the container element. The aria-selected = true|false would apply to the selectable items. There is no aria-selectable, but if aria-selected is not undefined, selectability is assumed (by browser, and exposed to platform accessibility layer).
Changed January 02, 2009 04:47AM UTC by comment:3
milestone: | TBD → 1.next |
---|
Changed November 03, 2011 12:26PM UTC by comment:4
component: | [meta] ui.a11y → ui.selectable |
---|
Changed October 03, 2012 04:48PM UTC by comment:5
milestone: | 1.next → 2.0.0 |
---|
Changed October 16, 2012 01:09PM UTC by comment:6
status: | new → open |
---|---|
summary: | Add ARIA semantics to Selectable → Selectable: Add ARIA semantics to Selectable |
Changed October 28, 2013 03:23AM UTC by comment:8
summary: | Selectable: Add ARIA semantics to Selectable → Selectable: Add ARIA semantics and keyboard handling |
---|
Per #9634 the widget should be focusable with the keyboard.
Changed October 29, 2013 12:17AM UTC by comment:9
This will require more than simply implementing these attributes. Will require role="option" and role="listbox" as well as potentially aria-multiselectable.