Closed Bug 494346 Opened 13 years ago Closed 13 years ago

STATE_FOCUSABLE not exposed on focusable video sliders


(Core :: Disability Access APIs, defect)

Windows XP
Not set





(Reporter: MarcoZ, Assigned: surkov)


(Blocks 1 open bug)


(Keywords: access)


(2 files)

Found after bug 490287 landed. NVDA does not properly go into focus mode because the sliders, although focusable, don't expose the focusable state.
Attached patch patchSplinter Review
Assignee: nobody → surkov.alexander
Attachment #379143 - Flags: review?(marco.zehe)
Attachment #379143 - Flags: review?(david.bolter)
1) Bug doesn't make sense if controls aren't focusable
2) I introduced action "activate" on slider accessible
3) I do know what I fixed in bug 492518 and what my reviewers reviewed but that fix makes nothing :) so I fixed it here.
Attachment #379143 - Flags: review?(david.bolter) → review+
Comment on attachment 379143 [details] [diff] [review]

Looks okay. r=me

> nsXULSliderAccessible::GetValue(nsAString& aValue)
> {
>   return GetSliderAttr(nsAccessibilityAtoms::curpos, aValue);
>+nsXULSliderAccessible::GetNumActions(PRUint8 *aCount)
>+  *aCount = 1;
>+  return NS_OK;

Maybe file a follow up to add more actions.
Attachment #379143 - Flags: review?(marco.zehe) → review+
Comment on attachment 379143 [details] [diff] [review]

r=me. This causes all the sliders to behave in a predictable manner when pressing ENTER on them from NVDA's virtual buffer.
I have to press ENTER on the "unknown object" accessible which is the anonymous xul:label which we marked up as presentation to get focus to the scrubber. BUT we can deal with that separately.
Comment on attachment 379143 [details] [diff] [review]

a191=beltzner; please land on mozilla-central first, and if all the boxes stay green, you can land on mozilla-1.9.1
Attachment #379143 - Flags: approval1.9.1+
Pushed on Alexander's behalf in changeset:
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #3)

> Maybe file a follow up to add more actions.

David, if it will be you then I would be happy ;) What kind of actions do we expect? We need to check this with ATs.
Blocks: 492516
Attached patch patch 1.9.1Splinter Review
Attachment #379143 - Flags: approval1.9.1+ → approval1.9.1-
Comment on attachment 379143 [details] [diff] [review]

We no longer want this for trunk as the revised patch on bug 486899 was causing problems with the keyboard shortcuts, and this patch caused problems with the previous fix for 486899.

We may take it again at some point, but for now, it'll get backed out of the tree.
This was pushed to 1.9.1 before discovery of keyboard conflict, and backed out via bsmedberg.
It was backed out from trunk as well but there is no link on hg revision and there is no link on failing tests. So what's wrong with this bug because it can't affect on bug 486899 since it's pure a11y fix?
Resolution: FIXED → ---
Comment on attachment 379178 [details] [diff] [review]
patch 1.9.1

reaskin approaval on 1.9.1 - it's really good fix for xul:scale

1. It exposes focusable and focused states on slider accessible
2. It fires focus events on slider accessible
3. It exposes accessible action on slider accessilbe

So definitely we improve a lot the slider accessible even if this fix is not useful FOR video/audio controls because XUL sliders aren't focusable after bug 486899.
Attachment #379178 - Flags: approval1.9.1?
(In reply to comment #11)
> It was backed out from trunk as well

Sorry it is still there (I looked at 1.9.1 tree). So marking fixed again.
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Attachment #379178 - Flags: approval1.9.1? → approval1.9.1.2?
Comment on attachment 379178 [details] [diff] [review]
patch 1.9.1

David: can you help clarify if the concerns in comment 9 and comment 10 have been addressed?
Attachment #379178 - Flags: approval1.9.1.2? → approval1.9.1.3?
Attachment #379178 - Flags: approval1.9.1.3?
Comment on attachment 379178 [details] [diff] [review]
patch 1.9.1

Need an answer to Beltzner's question in comment 14. If you still want to land it on the 1.9.1 branch please re-request approval (for
Sorry for the delay, comment 14 got lost during a 5 week holiday. We'll need to user test this patch on a 1.9.1 tree and re-request if/when we confirm no keyboard conflicts.

Alexander: can you check this? And before requesting 1.9.1 let's IRC a bit.
Let's test both default action and accSelect. I'm curious if the latter works.
You need to log in before you can comment on or make changes to this bug.