The default bug view has changed. See this FAQ.

ARIA select widget should expose focusable state regardless the way they manage its children

RESOLVED FIXED in mozilla25

Status

()

Core
Disability Access APIs
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: surkov, Assigned: maxli)

Tracking

(Blocks: 2 bugs, {access})

unspecified
mozilla25
access
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Historically widgets like listboxes, trees never take a focus (while they have focusable items) but expose focusable state. ARIA widgets can be manage the focus by two ways: aria-activedescendant approach and focusable children approach. The former approach makes the widget focusable, the second one makes it non focusable by default. So the suggestion is expose focusable state on ARIA widget not depending on the way the widget manages it children. That makes ARIA widget consistent each with other and with native widget.
(Reporter)

Updated

6 years ago
Summary: ARIA select widget should expose foucsable state regardless the way they manage its children → ARIA select widget should expose focusable state regardless the way they manage its children
(Assignee)

Updated

4 years ago
Assignee: nobody → maxli
(Reporter)

Comment 1

4 years ago
Actually these roles should be covered:
* listbox
* grid
* tree
* treegrid

Perhaps I would add ARIA state map item like FocusableIfHasFocusableItem to handle all of them rather than hacking into Accessible class
(Assignee)

Comment 2

4 years ago
Created attachment 781181 [details] [diff] [review]
Patch
Attachment #781181 - Flags: review?(surkov.alexander)
(Reporter)

Comment 3

4 years ago
Comment on attachment 781181 [details] [diff] [review]
Patch

Review of attachment 781181 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/src/base/ARIAStateMap.cpp
@@ +331,5 @@
> +    {
> +      if (aElement->HasAttr(kNameSpaceID_None, nsGkAtoms::aria_disabled) &&
> +          aElement->AttrValueIs(kNameSpaceID_None, nsGkAtoms::aria_disabled,
> +                                nsGkAtoms::_true, eCaseMatters))
> +        *aState &= ~states::FOCUSABLE;

to stay on safe side I wouldn't remove FOCUSABLE state (for example when this state goes from native markup)

It seems you should do
if (aElement->HasDefinedARIAToken() && !aElemnet->AttrValueIs("false"))

::: accessible/tests/mochitest/states/test_aria.html
@@ +275,5 @@
> +  <a target="_blank"
> +     href="https://bugzilla.mozilla.org/show_bug.cgi?id=690199"
> +     title="ARIA select widget should expose focusable state regardless the way they manage its children">
> +    Mozilla Bug 690199
> +  </a>

pls keep bug numbers sorted
Attachment #781181 - Flags: review?(surkov.alexander) → review+
(Assignee)

Comment 4

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/35f1055fd217
https://hg.mozilla.org/mozilla-central/rev/35f1055fd217
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.