Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic ARIA Tooltips aren't being announced when aria-describedby points to new tooltip ID refs on the same element #4047

Closed
nvaccessAuto opened this issue Apr 3, 2014 · 8 comments
Labels
Abandoned requested reports or updates are missing since more than 1 year, author or users are not available. app/internet-explorer blocked/needs-external-fix bug

Comments

@nvaccessAuto
Copy link

Reported by bgaraventa on 2014-04-03 17:15
An ARIA Tooltip is formed when aria-describedby is set on the focusable element, which then points to the ID of an element that includes role="tooltip".

When new tooltips are rendered, and aria-describedby is dynamically changed to point to the new tooltip when the same element has focus, the new tooltip should automatically be announced.

The announced text should reflect the same value as accDescription in the accessibility tree, which is correctly updated in IE10 and in Firefox.

Steps to reproduce:

  1. Visit
    http://whatsock.com/test/dt_demo/Coding%20Arena/Inline%20Form%20Field%20Validation%20and%20Dynamic%20Help%20Tooltips/Dynamic%20Help%20Tooltip/demo.htm
  2. Type "f", and confirm that the wrong tooltip text is announced.
  3. Continue typing up to 5 characters in length, and confirm the correct tooltip text is never announced.
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2014-04-03 21:14
If I recall correctly, Firefox doesn't fire description change events, but I'll verify this. I'd guess the same is true for IE. We need this event to know when the description has changed.

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2014-04-04 00:45
Confirmed that Firefox, IE and Chrome don't fire the descriptionChange event. Filed MozillaBug:991969 and GoogleIssue:chromium:359857.

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2014-04-14 23:40
MozillaBug:991969 is fixed for Firefox 31. You should be able to test the fix in Firefox nightly in the next build (not sure when that is, so maybe wait a day).

@ehollig
Copy link
Collaborator

ehollig commented Jul 25, 2017

As @jcsteh said in #4047 (comment), MozillaBug:991969 was fixed for Firefox 31. Google Issue Chromium:359857 was fixed in January 2015. I believe this issue still exists in IE 11.

@ehollig
Copy link
Collaborator

ehollig commented Oct 24, 2017

As stated in #4047 (comment), this issue has been resolved for Chrome and Firefox. Testing in Internet Explorer and Edge still exhibits this behavior as described in #4047 (comment).

@Adriani90
Copy link
Collaborator

This still exists in IE11 and Edge. @feerrenrut is this something for Webfix project?

@Adriani90
Copy link
Collaborator

In Edge Chromium 81 this works as expected. So only IE is affected by this issue still.

@Adriani90 Adriani90 removed the z app/edge (archived) use app/edge/anaheim label Apr 25, 2020
@Adriani90 Adriani90 added the Abandoned requested reports or updates are missing since more than 1 year, author or users are not available. label Apr 14, 2023
@Adriani90
Copy link
Collaborator

Support for IE ended completely in 2022 and is automatically removed from machines that still have it after an Edge update in february 2023. I am closing this as abandoned since I don't expect any further accessibility updates to IE or to IE mode in Edge.

@Adriani90 Adriani90 closed this as not planned Won't fix, can't repro, duplicate, stale Apr 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Abandoned requested reports or updates are missing since more than 1 year, author or users are not available. app/internet-explorer blocked/needs-external-fix bug
Projects
None yet
Development

No branches or pull requests

3 participants