WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: question

for

From: glen walker
Date: Apr 12, 2022 10:56AM

Agreed. Code inspection is typically the best way to see if the code is
causing the problem (which is usually the case). There are times when the
browser's accessibility tree isn't correct (albeit rarely) and times when
the screen reader is not presenting the accessibility tree correctly (also
fairly rare). I would guess (purely anecdotal) that 99% or higher are
failures in the code. I rarely find a screen reader or browser bug. But I
hesitate to say it's the "developer's fault". Sometimes it comes from the
library that's being used (which I guess you could say is the developer of
the library's fault). Most accessibility coding issues just come from lack
of knowledge and finding whose fault it is is irrelevant.

Sometimes the problem can be because of your screen reader settings. For
example if a particular landmark is not announced, it might not be set to
announce in your verbosity settings. Or if numbers are announced
differently than you expect, it might be a setting or it might be the way
that particular screen reader interprets the numbers.

I did find a recent JAWS bug that was pretty cool. If you have an input
field that has a label (whether via a label element or an aria label) *and*
the input has a placeholder with commas in the text, then the commas were
being escaped with a backslash character in front of them and that
backslash was being announced with the placeholder text.

See https://github.com/FreedomScientific/VFO-standards-support/issues/500

If you think you found a screen reader bug, check the respective screen
reader's bug list. I don't think Apple makes their bug list public.

JAWS - https://github.com/FreedomScientific/VFO-standards-support/issues
NVDA - https://github.com/nvaccess/nvda/issues