Closed scottaohara closed 1 year ago
Thanks @scottaohara will test in latest
@scottaohara tested with JAWS 2022 could reproduce. Then tested with JAWS 2303.2306.38 (June update) and chrome Version 114.0.5735.199 (Official Build) (64-bit). could not reproduce.
thank you @stevefaulkner
In testing the chrome canary implementation of using the
name
attribute to associatedetails
elements HTML PR 9400 having more context for this update, JAWS 2022 with chromium browsers (not firefox) were using thename
attribute to give thedetails
an accessible name.This resulted in the following reduced code example being announces as multiple "test" groups.
This does not appear to be reflected in the a11y tree of chrome, and latest NVDA, for instance, did not announce these elements as being named, either.
Further testing shows that it isn't just
details
that this was happening with, but other HTML elements which can be given an accName (but not all) would inconsistently get an accName from thename
attribute. Leading me to believe there is something specific with JAWS/Chrome and that maybe this is an attempt to mitigate author error (maybe for those thinkingname
will "name" an element)?Expected result
Do not expose the value of a
name
attribute as the accName for an element. Particularlydetails
elements as with the HTML change, it will become expected to usename
on these elements for a purpose that is not to provide the element an accName.Example
A test case that demonstrates the issue.
Additional Information
JAWS version and build number
JAWS 2022 (don't have build number on me at this time) - i realize i'm not using the latest JAWS version - so I realize there's a possibility that the latest version doesn't replicate, which would be great. but, this seems rather specific/potentially on purpose, so not too sure...
Operating System and version
Win 11
Browser and version:
Chrome canary latest