Skip to main content

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 davidb 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 scottgonzalez 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 scottgonzalez comment:3

milestone: TBD1.next

Changed November 03, 2011 12:26PM UTC by scottgonzalez comment:4

component: [meta] ui.a11yui.selectable

Changed October 03, 2012 04:48PM UTC by scottgonzalez comment:5

milestone: 1.next2.0.0

Changed October 16, 2012 01:09PM UTC by petersendidit comment:6

status: newopen
summary: Add ARIA semantics to SelectableSelectable: Add ARIA semantics to Selectable

Changed October 28, 2013 03:21AM UTC by tj.vantoll comment:7

#9634 is a duplicate of this ticket.

Changed October 28, 2013 03:23AM UTC by tj.vantoll comment:8

summary: Selectable: Add ARIA semantics to SelectableSelectable: Add ARIA semantics and keyboard handling

Per #9634 the widget should be focusable with the keyboard.

Changed October 29, 2013 12:17AM UTC by dylanb comment:9

This will require more than simply implementing these attributes. Will require role="option" and role="listbox" as well as potentially aria-multiselectable.