946226 - The Need For aria-hidden, And The Search for Alternatives

Status: RESOLVED DUPLICATE of bug 1349223

(Core :: Disability Access APIs, defect)

Description

[Eitan Isaacson [:eeejay]]

Attachment: A modal dialog in Firefox OS

Alex asked me to put this down, so we could discuss this.

In Firefox OS there are a few places where we rely on aria-hidden to hide content from the screen reader user. It should be noted, that we *never* hide something that is in plain sight to non screen reader users. The situations where aria-hidden is used could be broken into four main reasons:

1. An item is "suggestively" invisible. What I mean by this is that it is 90% invisible, and is only slightly showing to tell the user that it exists. Examples:
  (a) A modal dialog may have an opacity of 0.85 to suggest that it is above other content, with only a hint of the layer under it.
  (b) A drawer provides a preferences screen, or top-level navigation UI (like a folder heirarchy view in email). When it is shown, the main screen is pulled off to the side. It is also, functionally invisible even though some of it protrudes. The only part of the drawer that should not be hidden is the top icon that toggles the drawer.

2. For performance reasons. I was recently asked to remove the invisible styling in the homsescreen for non-current pages because unhiding the next page as the user swipes provides poor performance. You could read about that in bug #930587. If you follow the comments there, you could see that I ended up using aria-hidden after exhausting all other options I could think of.

3. Layout bugs. I am not sure if it is a bug or part of the spec, but if you set visiblity: none on an iframe or its parent, the iframe's content does not get allocated the correct geometry, so things like window.innerHeight and innerWidth return 0, or something else.

4. Audio. If an app iframe is styled as visibility: none, or display: none, any audio it has playing is muted. Firefox OS has its how heuristics as when to play backgrounded app audio, and when not. So using aria-hidden does not interfere with audio.

Comment 1

[Eitan Isaacson [:eeejay]]

Attachment: A drawer screen in Firefox OS

Comment 2

[alexander :surkov (:asurkov)]

(In reply to Eitan Isaacson [:eeejay] from comment #0)
> Created attachment 8342379 [details]
> A modal dialog in Firefox OS
> 
> Alex asked me to put this down, so we could discuss this.
> 
> In Firefox OS there are a few places where we rely on aria-hidden to hide
> content from the screen reader user. It should be noted, that we *never*
> hide something that is in plain sight to non screen reader users. The
> situations where aria-hidden is used could be broken into four main reasons:
> 
> 1. An item is "suggestively" invisible. What I mean by this is that it is
> 90% invisible, and is only slightly showing to tell the user that it exists.
> Examples:
>   (a) A modal dialog may have an opacity of 0.85 to suggest that it is above
> other content, with only a hint of the layer under it.
>   (b) A drawer provides a preferences screen, or top-level navigation UI
> (like a folder heirarchy view in email). When it is shown, the main screen
> is pulled off to the side. It is also, functionally invisible even though
> some of it protrudes. The only part of the drawer that should not be hidden
> is the top icon that toggles the drawer.

was obscured state supposed to be a fix for that? bug 922751

> 2. For performance reasons. I was recently asked to remove the invisible
> styling in the homsescreen for non-current pages because unhiding the next
> page as the user swipes provides poor performance. You could read about that
> in bug #930587. If you follow the comments there, you could see that I ended
> up using aria-hidden after exhausting all other options I could think of.

Benoit said in bug 930587 comment 19 that accessibility should learn how to handle offscreen stuff properly. It sounds like we have a bug in a11y visibility state computation. Do I understand correct?

> 3. Layout bugs. I am not sure if it is a bug or part of the spec, but if you
> set visiblity: none on an iframe or its parent, the iframe's content does
> not get allocated the correct geometry, so things like window.innerHeight
> and innerWidth return 0, or something else.

Why do you need size of not visible things?

> 4. Audio. If an app iframe is styled as visibility: none, or display: none,
> any audio it has playing is muted. Firefox OS has its how heuristics as when
> to play backgrounded app audio, and when not. So using aria-hidden does not
> interfere with audio.

So you can't use visibility:none for audio stuff that should be played, what about to move it somewhere out of screen instead (absolute position)?

Comment 3

[Marco Zehe (:MarcoZ)]

(In reply to alexander :surkov from comment #2)
> (In reply to Eitan Isaacson [:eeejay] from comment #0)
> > 4. Audio. If an app iframe is styled as visibility: none, or display: none,
> > any audio it has playing is muted. Firefox OS has its how heuristics as when
> > to play backgrounded app audio, and when not. So using aria-hidden does not
> > interfere with audio.
> 
> So you can't use visibility:none for audio stuff that should be played, what
> about to move it somewhere out of screen instead (absolute position)?

On touch screen devices, we have to make sure that only stuff currently visible on the screen can be swiped to by next/previous item. Except for scrollable sub views like web page content. But in the case of fixed screens, we have to make sure from the top left, there is no going anywhere else, and from the bottom right, too. If we allowed to swipe and activate items not on the screen, activation taps would go where they are not supposed to.

Also the items described about modal dialogs or the hidden drawer fall into this category. Only if the drawer is in the foreground are we allowed to swipe to those items, and double-tap to activate them. If the drawer is hidden, items should not be accessible, and the user must not be able to activate them.

Comment 4

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #2)
> (In reply to Eitan Isaacson [:eeejay] from comment #0)
> > Created attachment 8342379 [details]
> > A modal dialog in Firefox OS
> > 
> > Alex asked me to put this down, so we could discuss this.
> > 
> > In Firefox OS there are a few places where we rely on aria-hidden to hide
> > content from the screen reader user. It should be noted, that we *never*
> > hide something that is in plain sight to non screen reader users. The
> > situations where aria-hidden is used could be broken into four main reasons:
> > 
> > 1. An item is "suggestively" invisible. What I mean by this is that it is
> > 90% invisible, and is only slightly showing to tell the user that it exists.
> > Examples:
> >   (a) A modal dialog may have an opacity of 0.85 to suggest that it is above
> > other content, with only a hint of the layer under it.
> >   (b) A drawer provides a preferences screen, or top-level navigation UI
> > (like a folder heirarchy view in email). When it is shown, the main screen
> > is pulled off to the side. It is also, functionally invisible even though
> > some of it protrudes. The only part of the drawer that should not be hidden
> > is the top icon that toggles the drawer.
> 
> was obscured state supposed to be a fix for that? bug 922751

It would fix case a, yes. After roc's feedback I realized that having an accurate obscured state would be very hard, and that the potential for false positives exists. So I am reconsidering that approach, sorry for my silence on that bug. It may simply not be feasible.

But it still does not address case b.

> 
> > 2. For performance reasons. I was recently asked to remove the invisible
> > styling in the homsescreen for non-current pages because unhiding the next
> > page as the user swipes provides poor performance. You could read about that
> > in bug #930587. If you follow the comments there, you could see that I ended
> > up using aria-hidden after exhausting all other options I could think of.
> 
> Benoit said in bug 930587 comment 19 that accessibility should learn how to
> handle offscreen stuff properly. It sounds like we have a bug in a11y
> visibility state computation. Do I understand correct?
> 

Our offscreen state is messy and misused, as you know. So I would not rely on it for anything. More on that below..

> > 3. Layout bugs. I am not sure if it is a bug or part of the spec, but if you
> > set visiblity: none on an iframe or its parent, the iframe's content does
> > not get allocated the correct geometry, so things like window.innerHeight
> > and innerWidth return 0, or something else.
> 
> Why do you need size of not visible things?
> 

The embedded content might need it for certain js calculations. I don't know if it is still the case, but that is how the homescreen app is initialized. So when it initializes when its parent frame was hidden, it would render wrong.

> > 4. Audio. If an app iframe is styled as visibility: none, or display: none,
> > any audio it has playing is muted. Firefox OS has its how heuristics as when
> > to play backgrounded app audio, and when not. So using aria-hidden does not
> > interfere with audio.
> 
> So you can't use visibility:none for audio stuff that should be played, what
> about to move it somewhere out of screen instead (absolute position)?

In bug #945194 we are discussing a case where we intentionally expose content to an AT, but not visibly. The conventional, status-quo, solution is to give a negative absolute offset, since screen readers nowadays read it. Here you are saying the opposite, absolute positioning an iframe should hide it from AT. So which is it? In other words, the argument against aria-hidden=false is that we could have things styled in a negative coordinate instead, and the argument here against aria-hidden=true is that we could do the same and expect it to be hidden from AT?

I would like the offscreen state to be more useful than it is right now, but unfortunately it is a challenge to use. Here is a breakdown of all the cases, and the quirks with each one.

 * An item is placed in negative offset. An unassisted user will not know it exists, unless there are focusable items, and they start tabbing. Then, in the best case they will notice that there are links because of the URL showing up on the bottom of the window, in the worst case pressing tab will not show a focus ring until they reach something in the viewport. For a screen reader user, it will be read without any distinction that it is offscreen. As touch screens are getting popular, even blind users will start getting confused about why they can navigate to an item by swiping, but it is nowhere to be found on the screen.

 * An item is off the viewport in a positive coordinate, and the viewport has overflow auto or scroll. There will be a scrollbar, and the user will be able to reach the content by scrolling, or jump straight to focusable items with tab. If a screen reader user is in object navigation, the view will typically scroll to the current cursor position.

 * An item is off the viewport in a positive coordinate, and the viewport has overflow hidden. The content will be clipped. Unless there is s focusable item, in which case pressing tab will change the viewports scroll offset and bring the item into view. Screen readers ignore overflow: hidden, the view will be scrolled and the cursor will land on any item below the fold.

As an AT developer, I would like to have a clear distinction between content that is accessible by scrolling and content that is not. The latter I would hide, and the former show. But as the tabbing case shows, there is a lot more nuance here. If I had the power to change HTML, and all browsers at once I would remove items from the tabbing order that are at negative offsets, and below the fold in overflow: hidden. Then all of this would be simpler: only items below the fold with overflow auto/scroll would be accesssible to AT. In the meantime maybe there is room in our states to provide some distinction from all these cases, dunno.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to Eitan Isaacson [:eeejay] from comment #4)

> > was obscured state supposed to be a fix for that? bug 922751
> 
> It would fix case a, yes. After roc's feedback I realized that having an
> accurate obscured state would be very hard, and that the potential for false
> positives exists. So I am reconsidering that approach, sorry for my silence
> on that bug. It may simply not be feasible.

as long as it works in most cases and it's stable and predictable then it may be possibly ok. Btw, does HTML5 inert look helpful here?

> But it still does not address case b.

Not sure I follow it. Do Android devices have similar UI?

> Our offscreen state is messy and misused, as you know. So I would not rely
> on it for anything. More on that below..

I see, let's try to figure out if it can be fixed

> The embedded content might need it for certain js calculations. I don't know
> if it is still the case, but that is how the homescreen app is initialized.
> So when it initializes when its parent frame was hidden, it would render
> wrong.

ok, got it, so you can't do visibility hidden because of implementation, at least until implementation is workarounded. A primary reason, I guess it needs to be renderable. So hopefully offscreen thing should work for that.

> > So you can't use visibility:none for audio stuff that should be played, what
> > about to move it somewhere out of screen instead (absolute position)?
> 
> In bug #945194 we are discussing a case where we intentionally expose
> content to an AT, but not visibly. The conventional, status-quo, solution is
> to give a negative absolute offset, since screen readers nowadays read it.
> Here you are saying the opposite, absolute positioning an iframe should hide
> it from AT. So which is it?

so scrollable/appearable(like an element in background tab) should have offscreen state, not scrollable/appearable should have invisible state. So if you move something out of screen (negative absolute position) then we have an accessible, it's ignored by AT in general but you can refer it from anther elements and navigate to it. Actually I thought that's how Gecko works. Am I wrong?

Comment 6

[alexander :surkov (:asurkov)]

note, I filed bug 946370 about reader media type (as follow up bug 945194), that may be a solution of performance issue, since sometimes the app don't need to be so fast for screen readers users for example they won't care about blinking and other appearance-related things when miliseconds take a place.

Comment 7

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #5)
> if you move something out of screen (negative absolute position) then we
> have an accessible, it's ignored by AT in general
No, it's not. That's the solution currently used to provide information for screen reader users that isn't visible to sighted users, so ATs don't ignore it.

Comment 8

[James Teh [:Jamie]]

Eitan, is there something more to discuss here or can we close this? Now that bug 1349223 has landed and aria-hidden is here to stay, for better or for worse, I tend to think we have bigger fish to fry and we should move on.

Comment 9

[Eitan Isaacson [:eeejay]]

Yeah lets close this.