Marco Zehe (:MarcoZ) Reporter
	Description • 10 years ago

As it turns out, one of the big communication problems that have plagued the doorhanger accessibility story is the fact that some use cases may have been info bar interactions rather than door hangers, since these act totally the same for screen reader users. They're both alert panels with text and buttons, and the only difference is visual, and some persistence that is with the info bar, but not the door hangers. The latter go away more easily.

I was not aware of these two different widgets until today. To my perception, being totally blind, I was always dealing with the same widget type.

To make it clear for screen reader users whether they're dealing with an information bar or a door hanger prompt, a label must be given to the panel (the same spot where the role "alert" and the aria-describedby is set) that labels these. Localizable strings should be added like:

Information for information bars
Question for door hangers

Or some more appropriate strings.

	James Teh [:Jamie]
	Comment 1 • 10 years ago

Using labels to communicate semantic information like this is never ideal. The fact that there is a semantic difference here suggests we might need new roles.

I'm not sure i follow what the difference is with regard to user interaction. Doorhangers disappear more easily, but what does this actually mean for the user? To put it another way, how would communicating this distinction help the user?

	Marco Zehe (:MarcoZ) Reporter
	Comment 2 • 10 years ago

Jamie, once bug 990045 is fixed, doorhangers would always be reachable via F6 and shift+f6, while info bars are never reachable via f6, but are following in the tab order after the top right search field. Moreover, the info bars stay until you explicitly close them, doorhangers can disappear if you ignore them long enough. A mouse user, for example, dismisses a doorhanger by clicking inside the document. Actions like activating links would dismiss doorhangers, too.

	:Gijs (he/him)
	Comment 3 • 9 years ago

Marco, can you clarify what we want to achieve here? Semantically, doorhangers and notification bars provide roughly the same information/interaction possibilities: you get a message, and a primary action and potentially secondary actions, and a close button.

The difference, as comment #1 and comment #2 suggest, is mostly about how they are currently keyboard-reachable and whether they collapse (visually) easily or not.

I'm not sure if/how these need to be distinguished because of these two differences. We could:

- make F6 include notification bars
- give them different roles if there are appropriate roles (comment #1 suggests there might not be?)
- use something like aria-live to ensure that the collapsing of the doorhanger (or the appearing of the notification bar) be more obvious

- ... something else?

At the moment I'm not clear what the desired approach is here, and what our options are accessibility-API-wise.

	Marco Zehe (:MarcoZ) Reporter
	Comment 4 • 9 years ago

The most irritating thing for users is that some of these things disappear at seemingly random intervals, others don't. Even I am not clear when some of these disappear exactly, for example. So the most important thing would be to indicate that these are no longer there. They have a role of "lert", which implies an aria-live of "assertive", so they get spoken as soon as they appear.

Making the info bars F6 reachable seems like a good idea in any case.

I am not sure if we can actually use live regions for something that disappears. Unless we add a hidden live region object that says "Infobar closed" or "alert closed" or something to that effect. But I believe text/object removals are not well supported in most assistive technologies, even though theoretically they are part of the live region spec.

	:Gijs (he/him)
	Comment 5 • 9 years ago

Marco, thanks, that's already super helpful. It sounds like we should improve the focus situation for notification bars, and fix notifications for "this thing just went away".

If it helps, notification bars go away "randomly" for sighted users as well - they can be defined as going away after a timeout of N seconds, or after you navigate away from the page. So I'm not sure how well we can define *why* they go away in whatever kind of notification we come up with. I think for sighted users it's usually either obvious or ephemeral (as in, same kind of persistency as OS X desktop notifications, ie they show you a message, and disappear after 'some time'). Do the latter kind maybe need a different role?

Jamie, can you comment as to how we can reliably indicate to screenreaders/AT that "this thing just went away"?

	James Teh [:Jamie]
	Comment 6 • 9 years ago

Screen readers don't often notify about objects which disappear (in a live region or otherwise) because it can be very annoying for the user and there isn't a nice, generic way to report this fact. That said, when the accessible disappears, Gecko should fire a hide event anyway, so I suppose screen readers *could* choose to report this if they wanted to. Once these notifications stay around for longer/are more predictable/are consistently focusable, notifying about their disappearance becomes less important anyway. So, in short, I don't think you should do anything specific. :)