Proposal to include visible aria-hidden objects, at least in some platform trees #1185
Comments
|
If the working group agrees with this change, I think we should probably update the text in https://w3c.github.io/aria/#tree_exclusion, which currently states:
Aside: If the working group does not agree with this change, we should probably update the text in https://w3c.github.io/aria/#tree_inclusion, which currently states:
My read of the current spec text is that because elements with Related aside: I believe the reason that is a SHOULD NOT is because Mozilla didn't want to make the change and thus would formally object to a MUST NOT. It isn't because we wanted to leave it up to user agents to introduce non-interoperable experiences. 😉 Something we need to find out from screen reader developers on Windows is whether or not these things suddenly appearing in the accessibility tree will be a problem. (It shouldn't be in Linux because I never removed the for-Mozilla sanity checks from Orca. But I don't know what everyone in Windows did with their just-in-case code.) |
|
Regarding Windows, JAWS is the one who has asked for this change.
|
|
The aria-hidden attribute was created because there are good reasons to hide visible content from screen reader users. Making this change would more or less completely undermine the point of having it. Does FS have quantifiable data in support of their proposal that they can share? A change like this would have serious consequences for screen reader users, so I think we'd want to be absolutely sure that the advantages to users outweigh the disadvantages before considering it. |
|
Agree with @LJWatson - sometimes there are good reasons to hide things from AT. Related to @joanie's comment, reminder that there are word changes for the inclusion/exclusion sections awaiting review in PR #1100. |
|
I plead to keep aria-hidden as it is. Too many exception rules (like for role=presentation) make it even more complicated to use ARIA correctly |
|
@JAWS-test, screen reader behavior would not change, and this would not affect authoring practices. We are only providing a way to work around issues pages are authoring incorrectly. The issue is that aria-hidden is misused quite often and the screen reader has no chance to address it. |
|
@LJWatson @carmacleod Screen reader behavior would not change. However, if a user contacts JAWS technical support because they cannot access something, JAWS would be able to provide steps to workaround the issue. Right now they cannot do any repair on these. Repair of bad content is something that needs to occasionally happen. |
|
Sorry, what does that mean “repair something”?
Thinking out loud here.
If that means that they have a financial incentive to script around others’ bad accessibility implementations, then I have a problem with facilitating that or making that easier. That makes the web worse, not better, for anyone except the individual fortunate enough to have an employer who is willing to pay for this one-time fragile workaround.
If it means something else, let me know, but it’s the worst thing when something is inaccessible, and the short-term fix is directly antithetical to the long-term solution, which is the case here because pragmatically speaking, once that pain point goes away, then it will never ever be pursued.
If it means a feature whereby you can say “show hidden elements” for example, so that aria-hidden can be ignored by the screen reader to facilitate access, I would see why that could be attractive as a work around, but I feel very conflicted making it easier to get around inaccessible pages. Obviously, as a user, I want this functionality (I do), but as someone who wants there to exist external network pressures; social, financial, and legal, I’m just not so sure.
Thoughts?
|
However, I understood your initial comments to mean that the screen reader behavior changes:
These are changes to the screenreader output, because currently aria-hidden causes the content not to be output by the screenreader even if it gets the focus. I am not against repair mechanisms in the screen reader. I am also in favour of not preventing them. But the repair mechanisms should not be defined in the specification:
A simple example:
For aria-hidden I can imagine the following:
|
|
@JAWS-test I think we agree then. We would still transmit the hidden status. The mechanism to render aria-hidden content would be via configuration. Otherwise, the current behavior is followed. As far as the focusable aria-hidden thing we're doing, this is for focus mode (as opposed to browse/virtual buffer mode). It doesn't make sense to say absolutely nothing if the user tabs and focus lands somewhere. If the focus lands somewhere that is aria-hidden, JAWS/NVDA etc. will try to read something useful, when used with Chrome, so that the user isn't completely lost. There were too many pages putting aria-hidden on the body element when a modal dialog was open. Sad. |
|
@aleventhal commented:
Screen reader behavior would not change. However, if a user contacts
JAWS technical support because they cannot access something, JAWS would
be able to
provide steps to workaround the issue. Right now they cannot do any
repair on these. Repair of bad content is something that needs to
occasionally happen.>
There is no guarantee that screen reader behaviour won't change. FS
effectively pulled support for aria-controls last year, burying the
toggle to enable support somewhere deep in Jaws' settings.
As I mentioned above I think we need some actual data for a decision
like this. How often do authors get this wrong to the extent it damages
the user experience? Is it significantly more often than they get it right?
@sinabahram commented:
If that means that they have a financial incentive to script around
others’ bad accessibility implementations, then I have a problem with
facilitating
that or making that easier. That makes the web worse, not better, for
anyone except the individual fortunate enough to have an employer who is
willing
to pay for this one-time fragile workaround.>
It does seem as though this is being requested to assist FS with its
Jaws scripting services.
|
|
This isn't about scripting or consulting. Our intention for JAWS is to expose a user configurable option that says "Ignore ARIA Hidden on this page" that could be enabled on a per-page or per domain basis to allow users to function in the face of incorrect markup. We agree that aria-hidden provides a valuable role when used properly and we don't want to alter the default. But we do want to empower users to get things done when aria-hidden on pages would otherwise prevent it. As things stand, screen readers can't do any user directed remediation because aria-hidden content never makes it into the accessibility tree. |
|
Here are a couple of cases where aria-hidden is improperly used. In both of them, the misuse is in third-party javascript libraries that the developers of the apps in question can not easily change. |
|
We're just trying to solve a technical problem. Sorry that I don't have numbers, but this came up twice in crbug.com in the last year, which is actually surprising given that we don't get very many external bugs filed. Glen mentioned separately to me that it comes up as a support issue. We don't really have a way a measuring "when someone gets it wrong", which is the same reason we wouldn't automate anything about it. On the bigger picture, I didn't know we were still discussing as a community whether to enable users to make repairs. I think we have to be realistic about the fact that ARIA is one of the easiest technologies for authors to get wrong. There is so much expertise required to build a web app, and ARIA is only one small piece that a given developer needs to understand. Most authors aren't very comfortable with screen readers and not everything gets tested as much as it should. The spec is complex, and I still get things wrong about it myself. For example, it's really easy to break aria-hidden by assuming it works like CSS visibility -- that aria-hidden=false on a descendant undoes things aria-hidden on an ancestor. And when aria-hidden=true gets applied to the body, a sighted tester won't even notice. (Perhaps we should consider prohibiting aria-hidden on the top frame's body or html element, or perhaps we should allow aria-hidden=true on descendants to make that part of the tree visible, which would be helpful in the modal dialog case. There have been arguments about whether it's right to enable repair of bad content, for example whether auto alt is a good idea. I think that because of the reality of how often accessibility is done incorrectly, and how hard it is for even developers who care to get it 100% correct, we should at least make repairs possible. Users have things to get done, and not all are in a position to go call up a company and wait for probably never to get a fix. We aren't successfully changing things by making users suffer more. I asked a recent very knowledgable accessibility QA engineer, who didn't know my history of ARIA, for an honest assessment of how often ARIA makes a page better vs. worse. She said it makes it better about half the time, and worse about half the time. I don't know how to measure it, but I do know that if I'm a user trying to hold a job or get something done, I don't want to for developers to make an accessibility fix when they may be focused on something else, for whatever reason. Apologies for the long spiel, but I don't think we should need to argue about enabling repair scenarios going forward. Maybe I'm just too forgiving of developers not getting accessibility right all the time! But it is definitely super easy to break accessibility with ARIA, by its very nature. |
|
I don't think there's any doubt that aria-hidden is sometimes misused,
any more than there is doubt that it's used properly too.
That's why we shouldn't base a decision like this on single examples. We
should be absolutely sure that it's misused more often than it's not,
and that when it's misused there are no alternatives to working around that.
|
|
Sorry, that was an accidental click. Not a statement, haha, although I do find this conversation a little frustrating :/ |
|
Hi @LJWatson I think I probably didn't explain the proposal well. For this idea, do you think we need to prove it's misused more often than used properly? |
|
@aleventhal I am ok with this proposal now. I didn't fully understand it at first.
We need to get @cookiecrook to weigh in on this. You mentioned an email to NVDA in #1185 (comment) but it would be nice to hear from @jcsteh in this issue. @LJWatson I think I may be able to get some rudimentary data. I'll get back to you within the hour. Also, as @joanie mentioned above, if the WG agrees with this change, we would need to make changes to the inclusion/exclusion sections of the spec. I would appreciate it if we started with the words in PR #1100. |
Yes, with the possible exception of platforms where this isn't implemented yet. |
|
As much as I understand the real world implications here, I'm super reluctant to go down this path. For many years, Firefox didn't prune aria-hidden objects from the tree, precisely because of the concerns raised here. Part of the reason we ended up finally doing this after so many years was many complaints from authors and AT vendors that we weren't complying with the spec (despite our belief that we were doing the right thing for users), which caused friction because different implementations were doing different things. Despite the obvious issues, at least pruning aria-hidden trees was now clearly defined and consistent: if you use this badly, you get exactly the same result, regardless of browser and AT. Thus, a messy, years-long can of worms was finally closed. Now, we're talking about reopening this. The problem is that it's not as simple as just saying "stop pruning the tree":
And probably other issues I haven't thought of yet... |
|
@aleventhal, thanks for the detailed response, and sorry if you find the conversation frustrating. I think it's helpful, though, and I would like to humbly point out that just trying to solve a technical problem is how a lot of significant usability problems start, and most of the time, under the best of intentions. It's also abundantly obvious that this is one of those issues that engenders a strong response given past discussions, perhaps not all of which have been experienced by everyone, so your patients is appreciated. I of course am very interested in and thankful for the issues that @jcsteh brings up. |
|
@LJWatson In case it's interesting, here is the full list of web pages scanned. |
|
@LJWatson Here's a really quick surface analysis of some of the uses:
Here are a few oddities. I didn't look at any of these in situ (i.e. CSS/JS may fix them).
If anyone wants to do a deeper analysis of any of these 529 aria-hiddens, I've pasted the details below. 529 instances of aria-hidden in popular web site home pagesAttribution and appreciation to Majestic Million for their list of the top million websites. |
|
@jcsteh some of the concerns seem to be the amount of work, and some others, I think are addressed by exposing both the state and object attribute, which is what Chrome does for aria-hidden focusable objects. We don't seem to have any issues with that. Regarding hit testing / mouse tracking, doesn't NVDA respect the results that come back from accHitTest()? Isn't it up to the browser to not return hidden objects there? I'm not sure about going through all these concerns point by point, because I feel like in general people are against this either way, and this really only affects poorly authored pages. Would everyone be happier if we defined some cases where aria-hidden is invalid?
|
|
Closing this issue as it is more controversial than I anticipated. |
|
For what it is worth, I do not believe the browser should ever ignore aria-hidden.
|
|
@sinabahram what should a user do that needs to access hidden content? |
|
@aleventhal, a few different concepts come to my mind when considering this.
Should the browser ever ignore aria-hidden automatically?
I struggle with that and err on the side of no because I am incredibly concerned about these kinds of author mistakes not being appropriately flagged, remediated, and used for educational purposes. We’ve had a similar discussion to this on another thread, so I don’t wish to bring up the same concerns, which triggered a strong response, but I do not believe that the browser should always fix something, which would prevent the appropriate actions to be taken by authors, content creators, business owners, etc. to resolve things in a more meaningful and comprehensive way, especially a way that adds to the experience of developers for future websites they create.
If we aren’t talking automatically e.. there is a context menu that says “ignore aria-hidden on this page and reload” or something along those lines, then of course there’s a slippery slope to be aware of, for sure, but I find myself at least thinking of that as a dev or power-user tool with potential benefits. Does the user know the content they need to access is incorrectly aria-hidden? That seems like it would be true for an incredibly small amount of users, though, so I’m not sure if that’s at all of interest compared to the browser doing it automatically, just in terms of reach.
I’m also concerned about situations where patterns exist that have a visible component, which is being aria-hidden on purpose to achieve a good experience for everyone e.g. imagine a card with a title, which is also a heading and a link, along with some CTA text, maybe an image, and then another link that says “learn more”, where it is guaranteed that those consecutive links always go to the same place. Now, let’s put aside the insufficiency of “learn more” as link text, because that’s a whole other set of issues, but one nice thing that can be done in those situations is to put an aria-hidden and tabindex of -1 on that “learn more” link, so that each card is only a single tab stop for sighted keyboard users, for screenreader users too, and the continuous “learn more” links don’t pollute an otherwise pleasant navigational and reading experience. Yup, other solutions exist as well, like block links, but I’m just laying out a super-common pattern that we’ve come across repeatedly.
I would imagine something like this being in conflict with a pattern like that, but maybe I’m wrong?
I suppose my metric would be that the browser has the potential to make something worse, not better, by ignoring aria-hidden, and also that philosophically, shouldn’t the author’s intentions be respected, even when they are wrong?
|
|
If browsers respect aria-hidden on focusable element I'm worried the user will reach something with no accessibility properties. I'd argue that if aria-hidden is applied to a focusable element that is not inert, hidden, or otherwise removed then aria-hidden true should not be legal. I can't think of a case where aria-hidden true on on something that has active keyboard focus is ever a good idea. |
|
I’m neither advocating for this nor not, but just to point out that some folks may put aria-hidden=”true” on something, not put tabindex=-1 because they actually want the thing to get focus, then dispatch those focus events to an offscreen accessible version, while visually changing state on-screen, thereby keeping a 1-to-1 state between on/off-screen.
Again, not advocating for it, just stating it very much exists.
|
|
I'd be fine with an explicit tabindex=-1 and aria-hidden true to cause a focusable element not be in the tree. My concern is more with things that can actively be focused. |
|
Right, but that’s the opposite of what I said, because they would not have the tabindex=-1 there, no?
|
|
Hi, Here is a real-world example of why. There is an application called Resilio Sync, which is a folder synchronizing application that works across various platforms. When you first run the installer, you have to sign in through your web browser, and they incorrectly have aria-hidden="true" on the body, and aria-hidden="false" on the dialog that has the required account creation form fields, under the mistaken impression that one will cancel out the other. Because browsers are incorrectly handling this by hiding focusable form fields, it is literally impossible for all non-sighted screen reader users to sign up for this process. So, because I use this application a lot, I had to write a JavaScript bookmarklet that I can run from an external server that will scan the page I'm on and automatically remove every instance of aria-hidden="true" that it finds, just because there was no way for me to access this information otherwise. This is not a reasonable solution for the general public, and I was only able to do this myself because I was frustrated enough and I knew how to do it. I will argue that any element, as soon as it receives focus using any method supported by the browser for making an element focusable including tabindex="0" in the tab order or tabindex="-1" by using element.focus() to set focus to it programmatically, should always be exposed in the accessibility tree regardless whether it includes aria-hidden="true" or role="presentation" or role="none", especially since there is no way to override what browsers do in this context from within screen reader settings. |
|
@accdc, this isn't just about browsers having to do more work, although that is a significant issue; see #1185 (comment). However, aside from the fact that this is a backwards incompatible change, there are critical questions which haven't been satisfactorily addressed; see #1185 (comment) and #1185 (comment), and those are just the problems I was able to come up with off the top of my head without putting much thought into it. IMO, until these are satisfactorily addressed, this is not something we should even consider implementing. |
|
I'd like to reopen this issue. Found 2 more reasons that should be discussed.
|
|
I don't understand your second point. Why are we talking about visible VS focusable. Did we agree that visible stuff with aria-hidden should not honor aria-hidden? I definitley agree there are valid usecases where visible content must be allowed to have aria-hidden, from icons who meaning is conveyed through other means to custom implementations of various controls where the author very much knows what they are doing from an accessibility perspective. |
|
@aleventhal thanks a ton for the chat. I'm 100% clear on this now. I withdraw my confusion. The issue at hand here is using the mouse while a screen reader is enabled. In that specific situation, the object with aria-hidden of true must be able to be read because the mouse is the indicator of regard not focus or virtual buffer position; therefore, it makes complete sense to consider that case for a variety of users from cognitive and reading differences to low vision folk to facilitating exploration by blind users. This in no way harms blind screen reader users just using the keyboard, as the invisible trait on Windows and other platforms can be used to indicate to the screen reader when to read and when not to read the object, simply based on whether or not invisible is set and mouse was used to get there VS keyboard or other means. |
|
FWIW, when Firefox finally implemented aria-hidden in the "prune the entire sub tree" sense, we got a complaint from one of the screen magnifier vendors, namely Dolphin, who had used our previous implementation of keeping aria-hidden stuff in a separate tree, to still be able to highlight, zoom in on, etc., these accessible objects. Because even though they were aria-hidden, they still had valid screen coordinates in our implementation. But because we were asked so often to comply with the spec, even though our approach had many advantages, which we also clearly communicated more than once, we caved in. But FWIW, I think we had both your new raised points already solved in Firefox until we caved in and pruned the tree. |
Then why is it hidden in the first place? For aria-labelledby/describedby, browsers already handle that. For other relations, it simply doesn't make sense.
So now we're defining aria-hidden as "content that shouldn't be spoken by a screen reader when using the keyboard or moving the focus". That's pretty AT specific and certainly isn't what the spec says. If we wanted that, it should be called aria-hidden-from-keyboard-sr or something. What about touch screens? Should it be hidden when moving by object with a touch screen? Should it be hidden from explore by touch? The fundamental problem here is that the semantic purpose of aria-hidden was always poorly defined. IMO, we should quit trying to re-specify aria-hidden and instead create new attributes that more accurately reflect the actual intent of the author.
That depends on your definition of "solved". NVDA mouse tracking users had aria-hidden content reported to them, which is what #1185 (comment) requests. But actually, this was reported as a bug against NVDA; see nvaccess/nvda#4322. So, apparently, this isn't always what people want in the real world. Which leads us back to the problem of trying to overload a single, vague attribute with several different intents. |
|
@jcsteh your point about necessary semantic attributes is accurate, but there's stuff that can be done now VS later. Are you not ok with doing something better about aria-hidden behavior now while something like better attributes can be discussed for 1.3/beyond? Trying not to let the perfect be the enemey of the good. |
|
I'm okay with "doing something better" if it doesn't cause backwards
compatibility problems and break a bunch of other use cases. Unfortunately,
we've been here before, so we know for certain that changing this as
proposed will certainly do both of these things. Otherwise, Firefox would
never have caved on this in the first place. Aside from the points I've
just raised, I raised several questions in prior comments which haven't
been satisfactorily addressed.
|
|
@aleventhal replied to this, but (I assume accidentally) commented in nvaccess/nvda#4322 (comment) instead of here. Pasting his reply below. jcsteh: I'm okay with "doing something better" if it doesn't cause backwards aleventhal: Regarding compatibility issues: presumably you mean on Windows, so with JAWS or NVDA, right? I’m not aware of any compat issues. If the accessibility object has STATE_SYSTEM_INVISIBLE and the “hidden:true” object attribute, that should work the same as not exposing the object in terms of virtual buffer navigation. In terms of focus and x,y position reporting, I believe the AT should announce the objects. Regarding breaking use cases: can you enumerate a few of these? Is this the issue described in the NVDA bug? aleventhal (from previous comment): Hidden content can be t he end target of a relation, whether aria-hidden, display:none, visibility-hidden, or content-visibility:hidden jcsteh: Then why is it hidden in the first place? For aria-labelledby/describedby, browsers already handle that. For other relations, it simply doesn't make sense. aleventhal: It makes sense for aria-labelledby and aria-describedby. In UIA, these need to point to objects. Narrator/UIA expects that, and not a flat string. It may not make sense with aria-hidden, but my point was that it already is important to be able to expose hidden objects for this case. But I agree this is a minor point compared to the others. jcsteh: So now we're defining aria-hidden as "content that shouldn't be spoken by a screen reader when using the keyboard or moving the focus". aleventhal: I agree that we’re saying the content should not be read by the screen reader, e.g. in a virtual buffer. However, if a focus event occurs on it, it should definitely be read. Focus must never be hidden from the AT, which is fundamental to accessibility compliance. If focus lands on something, it makes no sense not to announce it. There’s no sensible use case for that. jcsteh: What about touch screens? Should it be hidden when moving by object with a touch screen? aleventhal: I think Yes This seems similar to traversing in the virtual buffer. jcsteh: Should it be hidden from explore by touch? alevethal: I don't see this as fundamentally different from the mouse cursor case. The AT can chose to have a setting or inform the user that the object was marked hidden. jcsteh: The fundamental problem here is that the semantic purpose of aria-hidden was always poorly defined. IMO, we should quit trying to re-specify aria-hidden and instead create new attributes that more accurately reflect the actual intent of the author. aleventhal: Mistakes were made. New attributes would be great, but let’s fix what we have, too. jcsteh: …. this was reported as a bug against NVDA; see nvaccess/nvda#4322. So, apparently, this isn't always what people want in the real world. aleventhal: I just don’t understand this reported use case. If someone can see enough to use a mouse, and they point at something, it makes no sense to read nothing when this occurs. My opinion notwithstanding, if the object is exposed with the hidden state/attribute, NVDA can choose to do what it wants and not read the information if it thinks that’s best for its users. Or it can implement a setting, which it cannot do if the object is not exposed. Exposing the objects the the hidden state/attribute only returns choice back to the AT and users of the AT. Meanwhile, visual AT users should certainly be able to get announcements for all objects under the cursor. |
The new implementation would be backwards incompatible with the old spec. That is, any implementation that prunes the tree would be in violation of the new spec. Among other things, that makes for a pretty messy situation before the new spec becomes final. Recall that I said much of the reason Firefox started pruning the tree was because of user and author complaints. This doesn't just affect browsers and AT vendors. This would also cause problems on Mac and Android, at least for Firefox.
Some people seem to disagree with you on the x, y position reporting point. You'd have to query them for their use cases. But again, we're talking about backwards incompatibility. Something that has been expected behaviour for years will now change.
See point 4 in #1185 (comment) for one example.
My point is that this isn't how aria-hidden is defined. aria-hidden never said "hides content from screen reader browse modes". How is the author supposed to know when this will hide something and when it won't, when we're now being very AT specific about when this will and won't work?
Perhaps. On the other hand, how did focus get to it in the first place? Users don't just use tab. And if only the focused element is read and the user can't get at anything else for context, that could create some big problems. For example, as I noted in #1185 (comment):
Which brings us back to what we're exposing here. Are we exposing all aria-hidden subtrees or just "visible" ones as this issue title suggests? If "visible", we need to address the other questions I raised in #1185 (comment).
What about ARIA 1.0 modal dialogs, where aria-hidden is deliberately and correctly used to hide the content outside the dialog? Now, mouse and explore by touch users will hit that content and potentially be confused because it's not part of the dialog. Visually, it might be faded or similar so it's clear it's just "background", but this won't be at all obvious to a screen reader user. What about opacity: 0 and similar techniques, where the content really is invisible and aria-hidden is used to make that semantically clear to AT? Mouse/explore by touch shouldn't hit that content, but it will.
It can't because hit testing will always hit the hidden object, even if there's something else (ancestor, z-order) that should ideally be read in those use cases. I guess the AT could walk through the tree looking for a better target when it wants to make this choice, but that's getting into some pretty nasty performance territory. |
|
@jcsteh I'm sincerely curious if you have thoughts on how to resolve the current situation, or if you feel things should remain as-is. It feels like having your voice in a discussion to help move things forward is both necessary and extremely helpful, but I do note, and please forgive me if I've missed it, that asides from the suggestion of separate attributes, there's no alternative path laid out in your various messages. So, in short, what do you recommend? I think you obviously agree with @aleventhal that having a user who can't access their retirement account or some other vital system because of incorrect aria-hidden usage is bad (I think we all do). Are you saying that these alternative attributes you are suggesting comprehensively address the problem, or at least do so better than the proposed solution? Do you recommend the long route of simply having that person sue and hopefully in 3 to 5 years with probably less than a 25% chance of success, maybe something will happen, or do you feel there is room for technical solutions to help people in the mean-time while other remediations, be they educational, policy, and/or legal, are pursued? Just trying to figure out how to improve things as I feel we're going back and forth on technical matters where we're disagreeing on one proposed strategy instead of helping come up with a strategy that is more agreeable and helps people at the end of the day. I feel comfortable stating that our collective goal here is to improve things, so Jamie, what is your suggestion for how best that can be achieved independent of any previous proposals? Also, would a synchronous voice call help to hash this all out? |
|
@sinabahram, that's a fair comment. The sad reality is that I honestly don't think there is a way to do what is proposed here without problems I can't live with. However, I do think the mitigations discussed in #1254, #1255 and #1256 could work and I think it's much more likely we can reach consensus on those. |
|
@jcsteh thanks for that comment. Let's start there if we can before revisiting this thread. I have commented on each of those threads in an effort to move things forward. May I ask you to comment that you're good with any of the three that you are good with without further discussion so we may concentrate efforts on those that do require further discussion? |
Unfortunately, aria-hidden often gets applied to something that shouldn’t be hidden (e.g. an <iframe> in one case and on some icons that should be clicked in another). Currently, screen readers can’t do anything to really help in this situation. JAWS recently asked us to consider exposing all visible aria-hidden objects. If something is truly hidden via CSS it still will not be exposed.
This isn't unprecedented. We currently expose focusable aria-hidden nodes. When the author misuses aria-hidden, the user can at least hear where they are tabbing to, instead of complete silence.
There would likely be benefits, at least in Chrome's in terms of simplifying the logic.
We have a way of marking nodes as invisible on every platform except Mac. Therefore, on Mac, we would likely fall back on simply not including the node, or at least not including it in children. The node would still be able to fire events and expose its ancestry chain.
The text was updated successfully, but these errors were encountered: