Closed Bug 594586 Opened 14 years ago Closed 14 years ago

Screen reader accessibility for doorhanger notifications

Categories

(Firefox :: Disability Access, defect)

Product:
Firefox
Component:
Disability Access
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: faaborg, Assigned: Margaret)

References

Details

(Whiteboard: [doorhanger])

Attachments

(1 file)

patch [Checked in: Comment 34]
1.01 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
== background == The new site based notification system is a form of opt-in non modal dialog. It contains a control for the user to indicate "yes" to the question being asked, but otherwise ignoring the dialog and clicking outside of it will dismiss it. This isn't exactly the same as the user indicating "no," since they can go back and still say yes after dismissing the question, so we've been referring to them as "ok/meh" instead of "ok/cancel" A mockup of the design we are using can be found here: https://bugzilla.mozilla.org/attachment.cgi?id=466966 Details of all of the site specific notifications that are moving over to this new interface are in bug 588240 == problem == If the user is interacting with Firefox using a screen reader, they will be using tab to explore all options in the dialog box. Additionally, there isn't really such a thing as non-modal when you are dealing with audio, since things are read in linear order and you are expecting to hear all available actions (both yes and no). == possible sollution == Can we insert an invisible cancel command that only gets picked up by screen readers for these notifications?
When you say "clicking outside of it", does this include, say, clicking in an input field to focus it? If so, perhaps tabbing should also dismiss it, although this is a bit scary. Also, I assume that when you say an invisible "cancel" button, you mean an invisible "dismiss"/"meh" button? I think it's useful to first think about this from the perspective of a sighted user who primarily uses the keyboard instead of the mouse. (I assume such users still exist. :)) What would be the best interaction model for keyboard users? We can then worry about the screen reader specific stuff, but I'll wager it will fall into place once the keyboard interaction model is worked out. Another solution is to implement a context menu for the notifications which includes a Dismiss item. This avoids the special invisible button, as a context menu is invisible unless it is raised. This should perhaps also have a shortcut key to enable quick dismissal.
>I think it's useful to first think about this from the perspective of a sighted >user who primarily uses the keyboard instead of the mouse. enter: yes esc: meh (cancel, but with the option of a future yes) tab: meh (cancel, but with the option of a future yes) What I'm woried about is that normally a screen reader will say: "do you want to remember your password" "remember password" [tab] "cancel" [tab] "remember password" [tab] "cancel" While in this case it will say: "do you want to remember your password" "remember password" [tab] "remember password" [tab] "remember password" [tab]
Mockup looks like dialog and it confuses me a bit that tabbing dismiss it. Are there similar UI solutions? If the combobox control with available actions gets focused when the dialog appears then it's announced by screen reader automatically. If it's not focused then perhaps we should make this dialog to use role="alert". If tab is going to dismiss the dialog but that's the thing we should aware screen reader users about then 1) we could put this information into accessible name (aria-labelledby attribute usage, though it might be annoying to hear this every time) or put it into accessible description (aria-describedby attribute, we need to get back feedback from Jamie or Marco if this will work in this case).
(In reply to comment #2) > enter: yes > esc: meh (cancel, but with the option of a future yes) > tab: meh (cancel, but with the option of a future yes) I assume this means the notification gets focus when it appears? > What I'm woried about is that normally a screen reader will say: > "do you want to remember your password" "remember password" [tab] "cancel" > [tab] "remember password" [tab] "cancel" Not necessarily. There are plenty of other dialogs with only an OK button. Normally, there's no implicit cancel, but the keyboard interaction is the same. > "do you want to remember your password" "remember password" [tab] "remember > password" [tab] "remember password" [tab] If tab dismisses the dialog, why would it keep saying "remember password"? Also, how do sighted users know that clicking elsewhere or hitting tab will dismiss the dialog? If they don't and they just learn through experience, then I think you can do the same for screen reader users with the tab key.
(In reply to comment #4) > Also, how do sighted users know that clicking elsewhere or hitting tab will > dismiss the dialog? Hmm, thinking about this, I guess they don't, but they do know that there's only one button, so they expect that hitting tab will do something different. A screen reader user might try to explore the dialog with tab as you suggest and end up dismissing it unintentionally. It is possible for a screen reader user ot investigate the dialog with review commands, though, so it might be acceptable to just let users figure this out for themselves. Alternatively, there could be some sort of state or description on the dialog. It shouldn't be anything lengthy, but just something that informs the user of the interaction paradigm.
>Not necessarily. There are plenty of other dialogs with only an OK button. >Normally, there's no implicit cancel, but the keyboard interaction is the same. Ok, but these dialogs are usually informative, and have a single ok button for confirming that the user has received the message, right? >If tab dismisses the dialog, why would it keep saying "remember password"? Assuming that the dialog holds keyboard focus until it is dismissed. They seem to currently work this way. >It is possible for a screen reader user >ot investigate the dialog with review commands, though, so it might be >acceptable to just let users figure this out for themselves If we could inject an extra bit of text that said "hit esc to cancel" I think that would solve the problem as well.
(In reply to comment #6) > >Not necessarily. There are plenty of other dialogs with only an OK button. > Ok, but these dialogs are usually informative, and have a single ok button for > confirming that the user has received the message, right? Sure, but semantically, there's no difference in the interaction. > >If tab dismisses the dialog, why would it keep saying "remember password"? > Assuming that the dialog holds keyboard focus until it is dismissed. Ah. That would solve the problem of not knowing what tab will do. Btw, screen readers don't keep re-reading the focused button; they only read it once. If tab moves nowhere, tab speaks nothing. Personally, I would prefer this. > >It is possible for a screen reader user > >ot investigate the dialog with review commands, though, so it might be > >acceptable to just let users figure this out for themselves > If we could inject an extra bit of text that said "hit esc to cancel" I think > that would solve the problem as well. Requiring hidden "screen reader only" text is fairly inelegant, though. I think it's fair enough to expect that users may try escape to dismiss the dialog once they get used to the new type of notification. After all, I'm guessing that even sighted users still have to get used to the new interaction model, as intuitive as it might be. On the other hand, grabbing focus probably defeats the point of the notification being unobtrusive while still being obvious. After all, sighted users don't have to perform some action before they can continue using the browser. Here's one possible scenario that I think would work, but I'm not sure if it is in line with the goals of the doorhanger notification: 1. A notification appears. It does not get focus, but it has a role of alert and fires an alert event which will cause it to be read by screen readers. This is how sidebar notifications are currently handled. 2. Any buttons in the notification will have shortcut keys. Alternatively, the user can hit f6 to get to the notification. 3. Moving the focus anywhere else (including pressing tab) dismisses the notification. This makes it similar to the model for mouse users where clicking elsewhere dismisses the notification.
>On the other hand, grabbing focus probably defeats the point of the >notification being unobtrusive while still being obvious. After all, sighted >users don't have to perform some action before they can continue using the >browser. Also even with timers added to the ok button, there are some security concerns. If a game is trying to get you to hit enter a bunch of times and then tosses up the dialog box, it shouldn't also grab focus. (these are used for sensitive things like extension install). >1. A notification appears. It does not get focus, but it has a role of alert >and fires an alert event which will cause it to be read by screen readers. This >is how sidebar notifications are currently handled. >2. Any buttons in the notification will have shortcut keys. Alternatively, the >user can hit f6 to get to the notification. >3. Moving the focus anywhere else (including pressing tab) dismisses the >notification. This makes it similar to the model for mouse users where clicking >elsewhere dismisses the notification. This sounds fine to me, everyone cc'd should have more context than I do about what types of behaviors users of screen readers will expect (for instance, is f6 the normal way to access a recent alert message?)
(In reply to comment #8) > (for instance, is > f6 the normal way to access a recent alert message?) Not exactly. There's no standard key to access recent alert messages. However, f6 is the normal way to move between distinct sections or panels of an application, so it's reasonable to expect that users might try that if an alert appeared.
Alex F., a thousand thank yous for pinging us! Let's please not do any hidden screen reader only instructions. We could provide an object attribute via our gecko a11y module and leave that part up to the screen reader devs. The problem of whether to move keyboard focus or not is tricky given this is intended to be ephemeral. Regarding timing, if the user mouse clicks outside the notification area immediately, would it go away immediately? I don't have a good prediction on how likely sighted keyboard users would learn to use F6.
(In reply to comment #10) > Let's please not do any hidden screen reader only instructions. We could > provide an object attribute via our gecko a11y module and leave that part up to > the screen reader devs. I'd prefer to avoid this approach if possible, but it's certainly better than hidden text. > I don't have a good prediction on how likely sighted keyboard users would learn > to use F6. What about the shortcut keys?
Let's say we were designing this from scratch just for screen readers. I think the ideal interface would be that at certain moments the software would announce that a certain action was optionally available, and how to do it. So, for instance: "To share your location press F6" or "To remember your password press F6" In this case, we don't have to worry about where focus is, or even if the user is tabbing through the items in the panel correctly, the interaction is a single statement followed by the (optionally) confirming the action. This is also the interactive equivalent to the current design for people who are using the mouse. A message presents itself, but peripherally and optionally, and then it gets out of your way.
I think I agree where this is going. My opinion is that there should be a shortcut key (e.g. alt+o) to say ok. There should be a shortcut key to focus the notification (e.g. f6). The notification should be dismissed if the focus is moved anywhere else. These shortcut keys should be exposed as the accessible shortcut key for the control it is related to. I.e. alt+o for the Ok button. f6 for the notification container (not sure if its a dialog or what ever). It may be a little strange to have an accessible shortcut key on a container, but I don't see why this would be a problem. As long as the container also has role_alert, the screen reader should say something like: Alert do you want to remember this password? f6 ok button alt+o To be honest, I'd personally like to hear the f6 before the message, but that's a screen reader specific issue.
(In reply to comment #13) > f6 for the notification container I'm not sure this really needs to be exposed via accessibility APIs. F6 is a pretty standard key to move between panes. Doing this would be like QT's exposure of "enter" as the shortcut for default buttons. :) Nevertheless, I'm not going to argue this one too hard; I recognise that many users will probably try to hit tab.
What I was imagining is that F6 wouldn't change the focus area, as much as it would confirm and dismiss the action itself (or whatever keyboard shortcut makes the most sense). That would be the most analogous in terms of the interactive design, something that is peripheral and easy to opt in to. >I recognise that many users will probably >try to hit tab. We may want to support this as well so that they can get to the alternate options (always do the action, never do the action).
(In reply to comment #15) > What I was imagining is that F6 wouldn't change the focus area, as much as it > would confirm and dismiss the action itself (or whatever keyboard shortcut > makes the most sense). Ok. F6 shouldn't be used for this. There should be a shortcut key on the button which confirms the action; e.g. alt+r for Remember, alt+o for OK, alt+y for Yes. > >I recognise that many users will probably > >try to hit tab. > We may want to support this as well so that they can get to the alternate > options (always do the action, never do the action). Both the actions should have shortcut keys for quick activation. Imo, f6 should move focus to the notification where you can tab through the actions. Pressing tab without first pressing f6 would dismiss the notification. See comment #7.
I think I agree with comment 16 as it should work well for all keyboard users. Can we get a bug owner?
The button and menu items already have access keys (though I think the access keys for the menuitems only work once you show the menu, e.g. by focusing the button and using Alt+Down), and tabbing to the button works fine once the focus is in the popup. I tried a few things to get focus into the popup. panel.focus() didn't seem to work when I tried. F6 doesn't work either, despite it being handled at a low-level for "focus between documents". I don't know how focus works with panels, or whether there's a way to shift focus to a panel programmatically, but I think that's all we need to address the concerns here.
(In reply to comment #18) > I don't know how focus works with > panels, or whether there's a way to shift focus to a panel programmatically, > but I think that's all we need to address the concerns here. The panel also needs to fire an alert event to accessibility APIs and should probably have an accessible role of alert. I'm not sure how to translate this into Gecko speak. :) Marco?
Basically, the doorhanger should behave much like the notification bar. There's stuff in the XBL binding that helps here, like the AccessibleProvider.
blocking2.0: --- → betaN+
Assignee: nobody → margaret.leibovic
Version: unspecified → Trunk
This patch gives the panel focus when it's open. I don't think we need to change anything to fire events to accessibility APIs, since that's already being taken care of by the panel.
Attachment #490934 - Flags: review?(gavin.sharp)
Sounds good, can you create a win32 opt try build so Marco can give it a spin? It sounds like this might fix bug 595271 as well?
Comment on attachment 490934 [details] [diff] [review] patch [Checked in: Comment 34] We should get someone who knows accessibility to make sure that this is sufficient. Perhaps davidb can help with that?
Attachment #490934 - Flags: review?(gavin.sharp) → review+
(In reply to comment #22) > Sounds good, can you create a win32 opt try build so Marco can give it a spin? > It sounds like this might fix bug 595271 as well? I pushed to try. A build will be available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/margaret.leibovic@gmail.com-d0b203bf70d6.
Excellent. I think the remaining bit is whether we should also add role="alert" or not, given that it is probably only necessary if we did not autofocus the doorhanger. Let's see what Marco says.
(In reply to comment #21) > This patch gives the panel focus when it's open. I'm not sure this is a good idea. Correct me if I'm wrong, but as I understand it, these notifications aren't meant to be obtrusive, but are instead meant to be actionable only if the user desires. Setting focus to these would be a regression from the notification bar, which does not focus notifications and thus isn't obtrusive. See comment #7 and comment #16. (In reply to comment #25) > Excellent. I think the remaining bit is whether we should also add role="alert" > or not, given that it is probably only necessary if we did not autofocus the > doorhanger. If you're focusing something, you do not need the alert event. However, if you want the caption of the notification to be read (at least for NVDA), the role needs to be dialog or alert.
>Setting focus to these would be a >regression from the notification bar, which does not focus notifications and >thus isn't obtrusive. Two potential issues with grabbing focus: -user is typing in a field and their focus is moved out from under them -the user hits enter before they realize that a notification took focus and accidentally act on the notification
If we don't want the panel to get focus when it first opens, we will have to make some other change, since it currently does have focus. Right now, the panel gets focus when it first appears, but then it doesn't get focus if you bring it back by clicking on its anchor icon, and there's no way to tab to it. My patch changes this secondary behavior, giving the panel focus when it opens after clicking on the icon. I think it makes sense for the panel to have focus in this case, since the user is explicitly requesting to see the notification. Also, when the panel gets focus, the buttons inside it don't get focus, so the user would have to tab to a button before being able to act on it accidentally.
(In reply to comment #28) > If we don't want the panel to get focus when it first opens, we will have to > make some other change, since it currently does have focus. Right now, the > panel gets focus when it first appears I think this definitely needs ot be changed. It's obtrusive for keyboard users and it could be argued that this is a regression from notification bar notifications. > there's no way to tab to it. I think f6 is appropriate to move to the notification as per comment #7. It should probably focus the first button in the notification. > My patch changes this secondary behavior, giving the panel focus when it opens > after clicking on the icon. I think it makes sense for the panel to have focus > in this case, since the user is explicitly requesting to see the notification. Agreed.
(In reply to comment #29) > (In reply to comment #28) > > there's no way to tab to it. > I think f6 is appropriate to move to the notification as per comment #7. It > should probably focus the first button in the notification. This seems to be a more general XUL panel problem. For example, there's no way to tab/f6 back to the edit bookmarks panel if you move focus away from it. I think this needs to be fixed before we can open the notification without giving it focus.
(In reply to comment #29) > I think this definitely needs ot be changed. It's obtrusive for keyboard users > and it could be argued that this is a regression from notification bar > notifications. Seems like we should take this to a followup bug? The patch here is currently making the doorhanger work consistently (be it the first time it's shown or following times). Despite this bug having been filed with a broad scope, I think it would be helpful to take specific further issues to followups, if for no other reason than making the discussion easier to follow. :)
Depends on: 616136
It seems like this bug is having a hard time reaching a conclusions, so I filed bug 616136 as a follow-up to address the specific initial focus issue, since it would be nice to land the patch that's been sitting in here.
Whiteboard: [can land]
I'm a bit lost in this bug as well. I think so far we all agree: -the notifications need to be screen reader accessible (goal) -the notifications can't steal focus (bug 616136) questions: -do users have any way of knowing that F6 is how you move focus to a notification that has role="alert"? -how did users focus the old notification bar to interact with it?
Patch landed: http://hg.mozilla.org/mozilla-central/rev/3dc4147890e9 I think that we should move the conversation about focus over to bug 616136, because the answers to Alex's questions will determine how that bug gets fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [can land]
(In reply to comment #33) > -do users have any way of knowing that F6 is how you move focus to a > notification that has role="alert"? Not explicitly. However, f6 generally moves to different panes/sections, so it's a plausible interaction model without introducing something non-standard. > -how did users focus the old notification bar to interact with it? It was in the tab order, but being near the address bar, one of the easiest ways was to hit f6 and then tab to it from there. More commonly, the user would just hit the keyboard shortcut associated with one of the notification's buttons. (These are reported when the notification appears due to role="alert".)
>More commonly, the user would >just hit the keyboard shortcut associated with one of the notification's >buttons. (These are reported when the notification appears due to >role="alert".) Ok, then we need to be sure to report the keyboard shortcut for the main action command, and dismissing the alert.
(In reply to comment #36) > Ok, then we need to be sure to report the keyboard shortcut for the main action > command, and dismissing the alert. Is there actually a button to dismiss the alert? My understanding was that you just clicked outside of it to dismiss it, but perhaps I misunderstood.
You can press Escape to close the notifications.
(In reply to comment #38) > You can press Escape to close the notifications. Ah. I'm not quite sure how to expose that to a11y APIs, as there is no actual control to close them and thus no control to place the shortcut on. Hmmm.
can we create a hidden control that maps to esc and still gets read?
also, lots of discussion over in bug 615315 about if it will have the control or not. Generally speaking there is no other impact there for an audio only interface.
Attachment #490934 - Attachment description: patch → patch [Checked in: Comment 34]
Blocks: 617333
No longer blocks: FF2SM
Whiteboard: [doorhanger]
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: