STATE_FOCUSABLE not exposed on focusable video sliders

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: MarcoZ, Assigned: surkov)

Tracking

(Blocks 1 bug, {access})

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Found after bug 490287 landed. NVDA does not properly go into focus mode because the sliders, although focusable, don't expose the focusable state.
(Assignee)

Comment 1

10 years ago
Posted patch patchSplinter Review
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #379143 - Flags: review?(marco.zehe)
Attachment #379143 - Flags: review?(david.bolter)
(Assignee)

Comment 2

10 years ago
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]
patch

Looks okay. r=me

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

Maybe file a follow up to add more actions.
Comment on attachment 379143 [details] [diff] [review]
patch

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]
patch

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:
http://hg.mozilla.org/mozilla-central/rev/6e3296a9980b
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

10 years ago
(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.
(Assignee)

Updated

10 years ago
Blocks: 492516
(Assignee)

Comment 8

10 years ago
Posted patch patch 1.9.1Splinter Review
Attachment #379143 - Flags: approval1.9.1+ → approval1.9.1-
Comment on attachment 379143 [details] [diff] [review]
patch

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.
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f2b6a8093866
(Assignee)

Comment 11

10 years ago
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 12

10 years ago
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?
(Assignee)

Comment 13

10 years ago
(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.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
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 1.9.1.4)
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.