Closed Bug 780888 Opened 12 years ago Closed 12 years ago

Actually prune the aria-hidden tree

Categories

(Core :: Disability Access APIs, defect)

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

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: davidb, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [see bug 1123360]) 

Spun off bug 775621. See also bug 581096 for example of discussion we don't want to have again. NVDA ticket is here: http://www.nvda-project.org/ticket/2117

It seems the common/modern understanding of aria-hidden is that it prunes the tree. IE and Safari prune the tree. Also I think this will be good for Gaia and AccessFu (Firefox OS a11y).
(In reply to David Bolter [:davidb] (I'm back!) from comment #0)

> It seems the common/modern understanding of aria-hidden is that it prunes
> the tree. IE and Safari prune the tree.

I believe that's bad idea since
1) it allows to hide focus
2) not friendly to screen magnifiers
3) edge cases aren't clear, for example, does aria relation wins over aria-hidden

previously I pushed some thoughts on this: http://asurkov.blogspot.com/2012/02/aria-hidden-and-rolepresentation.html
(In reply to alexander :surkov from comment #1)
> 1) it allows to hide focus
One of the problems here is that no one (including the spec) is clear about what *should* happen if the focus is hidden. Everyone probably agrees that it is author error, but as a result, the behaviour if this happens is simply undefined. The result is that no one wants to take responsibility for what happens if an author does something this stupid. Until the expected behaviour is defined properly, this will be an obstacle for implementers. This is one of several reasons i think aria-hidden is just a bad idea and usually just a quick fix for bad authoring.
I don't recall either the good example of aria-hidden usage (however somebody told it can be used to hide offscreen or z-index stuffs that aren't visible for sighted users but still are operable by AT users).

All this obscurity of aria-hidden is a cause why I suggested to expose hidden object attribute on the accessible and all its descendants so that AT can decide whether it wants it or wants to ignore it. 

The typical scenario for screen reader would be to ignore those accessbiles but if the user tabs into them then AT can say like hidden object was focused.
(In reply to alexander :surkov from comment #3)
> > somebody told it can be used to hide offscreen or z-index stuffs that aren't
> visible for sighted users but still are operable by AT users
That should be exposed with the invisible/offscreen state, though.

> The typical scenario for screen reader would be to ignore those accessbiles
> but if the user tabs into them then AT can say like hidden object was
> focused.
It's not quite that simple. If a so-called "hidden" element gets focus and the user is in browse mode, we have to figure out what to do with the browse mode cursor, since it doesn't exist in browse mode.
(In reply to James Teh [:Jamie] from comment #4)
> (In reply to alexander :surkov from comment #3)
> > > somebody told it can be used to hide offscreen or z-index stuffs that aren't
> > visible for sighted users but still are operable by AT users
> That should be exposed with the invisible/offscreen state, though.

offscreen I guess what makes them reachable to AT users

> > The typical scenario for screen reader would be to ignore those accessbiles
> > but if the user tabs into them then AT can say like hidden object was
> > focused.
> It's not quite that simple. If a so-called "hidden" element gets focus and
> the user is in browse mode, we have to figure out what to do with the browse
> mode cursor, since it doesn't exist in browse mode.

I see so the browser should take care of this, for example, do not expose hidden object attribute on focusable elements. 

Perhaps we can force invisible state for aria hidden tree (except focusable stuffs)? Do AT need ever know that this accessible was aria hidden (not invisible due to other causes)?
(In reply to alexander :surkov from comment #5)
> offscreen I guess what makes them reachable to AT users
There are some cases (e.g. overlapping using absolute positioning) where stuff is hidden from sighted users, but Firefox (and other browsers) don't consider these nodes to be offscreen. I guess this is one possible use case for aria-hidden, though ideally it wouldn't be necessary.

> > If a so-called "hidden" element gets focus and
> > the user is in browse mode, we have to figure out what to do with the browse
> > mode cursor, since it doesn't exist in browse mode.
> I see so the browser should take care of this, for example, do not expose
> hidden object attribute on focusable elements.
Right, but this breaks John Foliot's use case at least (which is yet another argument in support of aria-hidden being a bad idea).

> Perhaps we can force invisible state for aria hidden tree (except focusable
> stuffs)?
That might work. For now, NVDA still ignores Gecko's invisible state, though I believe the reasons for this might have been fixed. I need to check this.

> Do AT need ever know that this accessible was aria hidden (not
> invisible due to other causes)?
I don't think a screen reader cares, but other ATs might.
(In reply to James Teh [:Jamie] from comment #6)
> (In reply to alexander :surkov from comment #5)
> > offscreen I guess what makes them reachable to AT users
> There are some cases (e.g. overlapping using absolute positioning) where
> stuff is hidden from sighted users, but Firefox (and other browsers) don't
> consider these nodes to be offscreen.

should we?

> > > If a so-called "hidden" element gets focus and
> > > the user is in browse mode, we have to figure out what to do with the browse
> > > mode cursor, since it doesn't exist in browse mode.
> > I see so the browser should take care of this, for example, do not expose
> > hidden object attribute on focusable elements.
> Right, but this breaks John Foliot's use case at least (which is yet another
> argument in support of aria-hidden being a bad idea).

which one? a link please?

> > Perhaps we can force invisible state for aria hidden tree (except focusable
> > stuffs)?
> That might work. For now, NVDA still ignores Gecko's invisible state, though
> I believe the reasons for this might have been fixed. I need to check this.

it should be on release channel for a while

> > Do AT need ever know that this accessible was aria hidden (not
> > invisible due to other causes)?
> I don't think a screen reader cares, but other ATs might.

ok
> > That might work. For now, NVDA still ignores Gecko's invisible state, though
> > I believe the reasons for this might have been fixed. I need to check this.
> 
> it should be on release channel for a while

Jamie that would be great if you could check this and please file new bugs on any remaining issues.
re: remaining invisibility work please note bug 722417.
(In reply to alexander :surkov from comment #7)
> > There are some cases (e.g. overlapping using absolute positioning) where
> > stuff is hidden from sighted users, but Firefox (and other browsers) don't
> > consider these nodes to be offscreen.
> should we?
Actually, they should probably be considered invisible, not offscreen. Oops. I suspect this would be extremely difficult, though. I can file a separate bug for that.

> > > I see so the browser should take care of this, for example, do not expose
> > > hidden object attribute on focusable elements.
> > Right, but this breaks John Foliot's use case at least (which is yet another
> > argument in support of aria-hidden being a bad idea).
> which one? a link please?
http://john.foliot.ca/aria-hidden/
The links he wants to "hide" will of course be focusable.
(In reply to James Teh [:Jamie] from comment #10)
> (In reply to alexander :surkov from comment #7)
> > > There are some cases (e.g. overlapping using absolute positioning) where
> > > stuff is hidden from sighted users, but Firefox (and other browsers) don't
> > > consider these nodes to be offscreen.
> > should we?
> Actually, they should probably be considered invisible, not offscreen. Oops.
> I suspect this would be extremely difficult, though. I can file a separate
> bug for that.

true, please do that.

> http://john.foliot.ca/aria-hidden/
> The links he wants to "hide" will of course be focusable.

This example looks reasonable. What about to keep invisible for those? You can keep them in browsing mode but ignore until they are focused (continuation of comment #5).
(In reply to alexander :surkov from comment #11)
> > http://john.foliot.ca/aria-hidden/
> > The links he wants to "hide" will of course be focusable.
> This example looks reasonable. What about to keep invisible for those? You
> can keep them in browsing mode but ignore until they are focused
> (continuation of comment #5).
That would be pretty difficult if the focused node is a descendant of a hidden node, since we wouldn't be tracking the focused node.

To be honest, I'm tempted to just treat that case as undefined and authors can deal with odd behaviour if they don't remove keyboard focusability (tabindex="-1").

So, going back to your original objections concerning pruning:
(In reply to alexander :surkov from comment #1)
> 1) it allows to hide focus
That's possibly going to happen anyway in the AT. At least this way, it'll be consistent across ATs.
> 2) not friendly to screen magnifiers
This is probably the most important objection. However, does using the invisible state pose problems for them too?
> 3) edge cases aren't clear, for example, does aria relation wins over
> aria-hidden
Not sure i follow this.

Btw, Chrome also prunes the tree.
(In reply to James Teh [:Jamie] from comment #12)

> > 2) not friendly to screen magnifiers
> This is probably the most important objection. However, does using the
> invisible state pose problems for them too?

It should depend on AT. Rationale is AT can get boundaries of invisible object and zoom this area in constant to when the tree is pruned.

> > 3) edge cases aren't clear, for example, does aria relation wins over
> > aria-hidden
> Not sure i follow this.

I meant something like
<input aria-labelledby="label">
<label id="label" aria-hidden="true">I am a label, please love me do.</label>

> Btw, Chrome also prunes the tree.

It seems people just tried to search a solution.

Anyway if we'd go with invisible state approach then
1) you don't need to provide any special support of aria-hidden
2) if invisible object is focused then you announce it but vb is likely broken

Is that correct and is it acceptable?
(In reply to alexander :surkov from comment #13)
> I meant something like
> <input aria-labelledby="label">
> <label id="label" aria-hidden="true">I am a label, please love me do.</label>
Afaik, aria-hidden is treated like any other type of hiding (e.g. css), so the same rules should apply.

> Anyway if we'd go with invisible state approach then
> 1) you don't need to provide any special support of aria-hidden
For now, I'm still reluctant to switch to using the invisible state in NVDA, as I'm not sure about some edge cases, so I think we'll still use the hidden attribute (for now). Therefore, if the tree isn't going to be pruned, I guess this should be wontfixed. Imo, the invisible state should still be exposed for aria-hidden for correctness (and in case we or other ATs start using it in future), but this needs to be checked with other magnification vendors.

> 2) if invisible object is focused then you announce it but vb is likely
> broken
Correct.
(In reply to James Teh [:Jamie] from comment #14)
> I think we'll still use the hidden
> attribute (for now).
This is now what we do in NVDA as of a few hours ago.
(In reply to James Teh [:Jamie] from comment #15)
> (In reply to James Teh [:Jamie] from comment #14)
> > I think we'll still use the hidden
> > attribute (for now).
> This is now what we do in NVDA as of a few hours ago.

Ok. Does it makes sense to expose hidden object attribute on every accessible in the subtree?
(In reply to alexander :surkov from comment #16)
> Does it makes sense to expose hidden object attribute on every
> accessible in the subtree?
It isn't essential for us, but it'd be nice. This way, if a descendant of an aria-hidden accessible gets focus, the user will be informed it is invisible when they query.
Closing as wontfix as Jamie suggested.

I'll file another bug for object attribute inheritance and stale with invisible state approach until we are certain on position.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Just some closing comments for the record:
1. I'd be happy for the tree to be pruned. However, I understand Alex's objections to this.
2. The fact that there is so much controversy here suggests a very serious problem with aria-hidden as it is currently specified.
2.1. Alex's concern about magnifiers suggests that aria-hidden doesn't actually apply to all ATs.
2.2. aria-hidden is used for wildly different purposes which have different impacts on various ATs. For example, if it is used to specify hiding of content which is truly invisible to sighted users (see comment 3), it probably *does* make sense to prune the tree (or at least expose the invisible state), as magnifiers shouldn't see this either. However, if it is used to hide content so it isn't spoken by screen readers even though it is still visible to sighted users (see comment 10), it doesn't make sense to prune the tree (and perhaps even expose the invisible state) because magnifiers *should* see this.
3. The hidden object attribute is currently non-standard as far as IA2 and ATK are concerned. Ideally, this should be standardised if it's going to be used, but trying to standardise this will raise the same problems as outlined in (2).
When I filed it I never intended to have the same discussions over again. I don't think there is anything to argue since we tend to all agree about aria-hidden. This bug was an attempt at interoperability.

I will be pursuing the removal of aria-hidden in ARIA 1.1+
(In reply to David Bolter [:davidb] from comment #20)

> I will be pursuing the removal of aria-hidden in ARIA 1.1+

aria-hidden doesn't look 100% useless idea and by removing it from the next spec you don't remove it from existing implementations.
(In reply to alexander :surkov from comment #21)
> (In reply to David Bolter [:davidb] from comment #20)
> 
> > I will be pursuing the removal of aria-hidden in ARIA 1.1+
> 
> aria-hidden doesn't look 100% useless idea and by removing it from the next
> spec you don't remove it from existing implementations.

It was originally put in for a DOM based AT which is no longer relying on only the DOM. But now that I think of it, I think AccessFu still wants this a pruning version of aria-hidden. Sigh. Anyways, this attribute has been the most expensive ARIA attribute already, and I'm not sure how much more time I can spend discussing it before I spontaneously combust.

Note it is actually likely Rich who may be pursuing spec removal. If there is yearning for more discussion wai-xtech is probably the place.
(In reply to David Bolter [:davidb] from comment #22)

> It was originally put in for a DOM based AT which is no longer relying on
> only the DOM.

it seems the feature started separate life

> Anyways, this attribute has been the
> most expensive ARIA attribute already, and I'm not sure how much more time I
> can spend discussing it before I spontaneously combust.

it's turning into a habit like having a tea at 5 o'clock

> Note it is actually likely Rich who may be pursuing spec removal. If there
> is yearning for more discussion wai-xtech is probably the place.

there are so many voices there :)
(In reply to alexander :surkov from comment #21)
> aria-hidden doesn't look 100% useless idea
It's terribly specified and probably needs to be split into at least two separate attributes, thereby separating the various purposes for hiding.

> and by removing it from the next
> spec you don't remove it from existing implementations.
That's true, but at least authors can be told that they should be using alternative techniques if they want to avoid this mess.
(In reply to James Teh [:Jamie] from comment #24)
> (In reply to alexander :surkov from comment #21)
> > aria-hidden doesn't look 100% useless idea
> It's terribly specified and probably needs to be split into at least two
> separate attributes, thereby separating the various purposes for hiding.

it's interesting idea

> > and by removing it from the next
> > spec you don't remove it from existing implementations.
> That's true, but at least authors can be told that they should be using
> alternative techniques if they want to avoid this mess.

agree
Hi - I just found this thread. Here are my thoughts from Chrome's perspective:

I don't think we should remove aria-hidden, it's quite useful. However, I do like the idea of splitting it into two separate attributes.

I think the best example of where aria-hidden is useful is when a page pops up a modal dialog. Setting role="dialog" and managing focus within the dialog works great most of the time, but if a user enters browse mode there's nothing preventing them from reading past the dialog and ending up lost inside the rest of the document. I've found that setting aria-hidden=true on everything other than the dialog works great, it means that while the modal dialog is open, even in browse mode all you get is the dialog. That works for both magnifiers and screen readers, because the rest of the content on the page really should be ignored as long as the dialog is open.

I would also like to come to some agreement as to what should happen when a control is focused and it's in a aria-hidden subtree. I'm not really worried about the case where that's an author error, because authors shouldn't be messing with ARIA at all if they don't know what they're doing - this is hardly the only way they can get themselves in trouble and make things far worse than doing nothing.

The idea of focusing something inside aria-hidden came while exploring how to make Google Docs accessible, but here's a simpler example to consider: suppose I have a custom spinbutton control that's implemented as a disabled text field and two buttons, but I want to expose it to screen readers as just one control with role=spinbutton? I'd like to do something like this:

<div tabindex=-1 role=spinbutton>
  <div class="accessible-text">
    25
  </div>
  <div aria-hidden=true>
    <input disabled value="25">
    <button tabindex=-1>+</button>
    <button tabindex=-1>-</button>
  </div>
</div>

In Chrome, when the input gets focused, it posts an accessible focus notification on the ancestor with role=spinbutton. That works great. In Firefox, currently, the notification still gets posted on the input even though it's supposed to be hidden.
> I think the best example of where aria-hidden is useful is when a page pops
> up a modal dialog. Setting role="dialog" and managing focus within the
> dialog works great most of the time, but if a user enters browse mode
> there's nothing preventing them from reading past the dialog and ending up
> lost inside the rest of the document. I've found that setting
> aria-hidden=true on everything other than the dialog works great, it means
> that while the modal dialog is open, even in browse mode all you get is the
> dialog. That works for both magnifiers and screen readers, because the rest
> of the content on the page really should be ignored as long as the dialog is
> open.

actually I don't like that very much, we don't make the modal dialog take up the page / screen so why should we do morally the same thing for the accessible tree?  I think the accessible should just be exposing the state of the UI, which includes the stuff outside of the dialog, of course if you think this is an issue you could make the dialog large enough to cover all of the content and then people won't be able to see the other stuff and it should have invisible / offscreen states in the accessible tree which according to your goal  would seem to be better?

Infact I don't think that really works for magnifiers since it seems reasonable for them to allow you to magnify any part of the screen that's visible, but not having an accessible tree for some of whats visible could hurt that.

> I would also like to come to some agreement as to what should happen when a
> control is focused and it's in a aria-hidden subtree. I'm not really worried
> about the case where that's an author error, because authors shouldn't be
> messing with ARIA at all if they don't know what they're doing - this is
> hardly the only way they can get themselves in trouble and make things far
> worse than doing nothing.

my first thought is given the way aria-hidden works today that is *always* an author error since your moving focus to something that doesn't exist.  However for some other attribute than aria-hidden that does something different maybe there's a reasonable behavior.

> suppose I have a custom spinbutton control that's implemented as a disabled
> text field and two buttons, but I want to expose it to screen readers as
> just one control with role=spinbutton? I'd like to do something like this:

part of me wants to say "don't try to do that", but I suspect what I think the right thing to do would depend on how exactly you interact with it.  If its with moving a ouse up / down over it then why are you bothering with all this when you could just do
<div role=spinbutton  onmouseup="blah();" ontouch="touchBlah();" ...>25</div>
on the other hand if you click on each of the buttons for up / down I'd probably go for giving the buttons there own accessibles.

> In Chrome, when the input gets focused, it posts an accessible focus
> notification on the ancestor with role=spinbutton. That works great. In
> Firefox, currently, the notification still gets posted on the input even
> though it's supposed to be hidden.

I'm willing to consider other attributes / meanings of aria-hidden, but given the current spec and how firefox handles it I'm just fine with our behavior.  First while you want it to not be its an author error, and if we did trim the accessible tree I'd be tempted to just not fire a focus event at all.

I'm not trying to say there is no problems to be solved, just that aria-hidden as is isn't a reasonable solution.
> I think the accessible should just be exposing the state of the UI,
> which includes the stuff outside of the dialog

What if the stuff outside the dialog is grayed out and/or blurred?
It's basically unreadable and not possible to interact with.

> you could make the dialog large enough to cover all of the content
> and then people won't be able to see the other stuff and it should
> have invisible / offscreen states in the accessible tree which
> according to your goal  would seem to be better?

I would be fine with that if screen readers actually hinted to users when they landed on something offscreen, but they don't. I'm concerned it's unlikely that they'll want to do that because of prevalent use of offscreen links intended explicitly for screen reader users.

Here are some ideas for replacements for aria-hidden:

aria-visible - for example, when something is grayed out or blurred so it's unreadable to sighted users.

aria-offscreen - to indicate something is offscreen on purpose and should be skipped by assistive technology too (i.e. it's not a hidden link for screen readers) - an example here is HTML slide decks where the next slide is rendered offscreen and animated in.

aria-autofocus - setting this to false could hint to a screen reader that they don't want to auto-focus an element when the user browses to it. explicitly focusing it would still be allowed so this would never break an incorrectly-written page. setting this to true could hint that this object can be interacted with in focus mode, like a combobox - even if items with that role wouldn't normally get focus
(In reply to Dominic Mazzoni from comment #28)
> > I think the accessible should just be exposing the state of the UI,
> > which includes the stuff outside of the dialog
> 
> What if the stuff outside the dialog is grayed out and/or blurred?
> It's basically unreadable and not possible to interact with.

then shouldn't it have the OPAQUE state?

> > you could make the dialog large enough to cover all of the content
> > and then people won't be able to see the other stuff and it should
> > have invisible / offscreen states in the accessible tree which
> > according to your goal  would seem to be better?
> 
> I would be fine with that if screen readers actually hinted to users when
> they landed on something offscreen, but they don't. I'm concerned it's
> unlikely that they'll want to do that because of prevalent use of offscreen
> links intended explicitly for screen reader users.

this gets into the question of the difference between offscreen and invisible, but if the content outside of the modal window is covered by the dialog then its invisible not just offscreen which I would think a screen reader would just not present.  I suspect its already available in the opaque / visible / offscreen states somewhere but the solution here seems to be to allow screen readers to know this is invisible because something is on top of it vs this is invisible because its scrolled off the screen.   In any case you seem to be trying to hack to deal with another hack to make existing software work instead of provide an API that allows screen readers to do a good job if they so choose.

> Here are some ideas for replacements for aria-hidden:
> 
> aria-visible - for example, when something is grayed out or blurred so it's
> unreadable to sighted users.
> 
> aria-offscreen - to indicate something is offscreen on purpose and should be
> skipped by assistive technology too (i.e. it's not a hidden link for screen
> readers) - an example here is HTML slide decks where the next slide is
> rendered offscreen and animated in.

these seem fine but I really wonder if you see cases where the UA can't do this on its own?

> aria-autofocus - setting this to false could hint to a screen reader that
> they don't want to auto-focus an element when the user browses to it.
> explicitly focusing it would still be allowed so this would never break an

TBH I'm not sure I understand how this would work, maybe Marco or Jamie have opinions since this seems to be fairly targeted at the way windows screen readers work.

> incorrectly-written page. setting this to true could hint that this object
> can be interacted with in focus mode, like a combobox - even if items with
> that role wouldn't normally get focus

This seems fine, but I wonder if there's a case where this wouldn't indicate the role not being focusable is a bug?
it may be worth looking at the HTML5 inert attribute:

http://www.w3.org/html/wg/drafts/html/master/editing.html#inert-subtrees

as this is designed to handle cases for the HTML <dialog> element
Dialog example looks as a good example of aria-hidden pruning the tree. However I'd say if ARIA had an attribute to specify a dialog is modal then screen readers and magnifiers could use that info to not go outside the dialog. IMO that would be more elegant than aria-hidden in this case.

<div>
  <input aria-hidden="true">
</div>

is a thin ice. For example, the div should expose focusable state. And then IAccessible::accSelect(SELFLAG_TAKEFOCUS) should focus it what means that aria-hidden input should be focused instead (on DOM level). If the div contains several focusable elements then it's not clear which one should be focused.

In Gecko we never hide the focus. Just to be on safe side. It seems the web is full of examples where people do crazy things and it'd be good if we didn't break accessibility because of that.

So we just expose an object attribute for aria-hidden letting AT to decide what to do with it.
(In reply to steve faulkner from comment #30)
> it may be worth looking at the HTML5 inert attribute:
> 
> http://www.w3.org/html/wg/drafts/html/master/editing.html#inert-subtrees
> 
> as this is designed to handle cases for the HTML <dialog> element

it sounds that @inert is a right solution for dialogs.
(In reply to alexander :surkov from comment #31)
> Dialog example looks as a good example of aria-hidden pruning the tree.
> However I'd say if ARIA had an attribute to specify a dialog is modal then
> screen readers and magnifiers could use that info to not go outside the
> dialog. IMO that would be more elegant than aria-hidden in this case.

That sounds fine for a dialog.

What about something that has similar properties to the dialog example, but there's no dialog?

What about the example of a slide deck like http://slides.html5rocks.com/? Many html5 slideshow apps render the previous and next slides purely for visual effect - you can see just 5% of each one on the sides of the screen. It's incredibly confusing for a screen reader to see three slides at a time - logically, only one slide is visible at a time, and just hints of two others are visible as a purely presentational detail.

So while I'm all in favor of both @inert and a modal attribute, I think they're too narrow - there are plenty of other cases that exist today where content needs to be hidden from all assistive technology - or at least marked up that it's invisible.

> In Gecko we never hide the focus. Just to be on safe side.
> ...
> So we just expose an object attribute for aria-hidden letting AT to decide
> what to do with it.

OK.

(In reply to steve faulkner from comment #30)
> it may be worth looking at the HTML5 inert attribute:
> 
> http://www.w3.org/html/wg/drafts/html/master/editing.html#inert-subtrees
> 
> as this is designed to handle cases for the HTML <dialog> element

Is AT supposed to skip over an inert section of a page by default? Because if not, it'd still be confusing for a screen reader user to accidentally jump past the end of a dialog and end up in the inert section of the document.

(In reply to Trevor Saunders (:tbsaunde) from comment #29)
> the solution here seems to
> be to allow screen readers to know this is invisible because something is on
> top of it vs this is invisible because its scrolled off the screen.

They already have that difference - the offscreen vs invisible states.

> In any
> case you seem to be trying to hack to deal with another hack to make
> existing software work instead of provide an API that allows screen readers
> to do a good job if they so choose.

Where possible, I have a slight preference to add web standards that make use of existing attributes that existing AT already understands. AT already understands "invisible", so giving a way for web authors to mark something as *effectively* invisible using ARIA seems useful. If we also need some attributes that don't currently exist for optimal results, that's fine too.

> > Here are some ideas for replacements for aria-hidden:
> > 
> > aria-visible - for example, when something is grayed out or blurred so it's
> > unreadable to sighted users.
> > 
> > aria-offscreen - to indicate something is offscreen on purpose and should be
> > skipped by assistive technology too (i.e. it's not a hidden link for screen
> > readers) - an example here is HTML slide decks where the next slide is
> > rendered offscreen and animated in.
> 
> these seem fine but I really wonder if you see cases where the UA can't do
> this on its own?

Consider the HTML5 slideshow as an example. A small portion of the previous and next slide are visible, so the user agent will consider them to be VISIBLE - but the web author wants to make it more accessible and less confusing by having AT ignore the slides that are 99% off the screen and only showing for visual effect. So the web author wants to mark them as invisible.

Today, the only way a web author can do this is with aria-hidden. I'm totally in favor of providing more nuanced and more useful ways of doing this - as long as there's a way.

> aria-autofocus

Sorry, this idea was a tangent, let's move the discussion of these to another bug, or the ARIA 1.1 discussion which I think will be happening soon.

I'm more interested in hearing thoughts on the best solution for the HTML5 slide example.
(In reply to Dominic Mazzoni from comment #33)

> What about the example of a slide deck like http://slides.html5rocks.com/?
> Many html5 slideshow apps render the previous and next slides purely for
> visual effect - you can see just 5% of each one on the sides of the screen.
> It's incredibly confusing for a screen reader to see three slides at a time
> - logically, only one slide is visible at a time, and just hints of two
> others are visible as a purely presentational detail.

I agree that those should be ignored by screen readers but I don't think screen magnifiers should ignore it too.  aria-hidden pruning the tree doesn't seem ideal here.

> So while I'm all in favor of both @inert and a modal attribute, I think
> they're too narrow - there are plenty of other cases that exist today where
> content needs to be hidden from all assistive technology - or at least
> marked up that it's invisible.

right, sometimes people need to hide visible things from AT, for example, to hide dupe content. But in either way I wouldn't hide focusable content.
Whiteboard: [see bug 1123360]
You need to log in before you can comment on or make changes to this bug.