WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: testing with JAWS and NVDA

for

From: Karlen Communications
Date: Apr 11, 2013 9:47AM

I don't think we are saying it is an excuse, I think what we are saying is
that we can't create AT centric compliance. We can't fail content because
one version of one AT on one computer gets confused or renders some content
incorrectly.

If something is coded or tagged correctly, and AT (for whatever reason) is
not identifying something correctly, then the problem is with the AT not the
content. We should not be creating AT centric content as it potentially
excludes access by different AT. Just because X is the market leader doesn't
mean it can perfectly render content. We need to consider access to the
content by AT in general. If we start coding and tagging to compensate for
shortcomings of a specific AT, we create a barrier for other At and we put
ourselves in the position of making that content useless to the AT centric
product if the issue is fixed or worsens in subsequent versions.

Here is my example: I have a complex table that is marked as per current
standards of table markup using header ID and anything possible to make the
information render logically to someone using AT. The X screen reader begins
reading the table in the logical order, providing all information supported
by the markup. Suddenly, the X screen reader begins jumbling the information
and reading it in a completely different order. I've seen this happen
randomly and I've seen this type of behavior happen consistently. My own
screen reader behaves differently on every computer that I own. Although
generally consistent, there are quirks depending on the computer. I can try
troubleshooting by refreshing the screen, closing the document and opening
it again, closing the app and opening it again...this may jog the quirk out
of happening but it doesn't mean that it won't happen again.

The document should not "fail" any type of accessibility compliance because
of a quirk or bug of the AT.

Another example is that in previous versions of X screen reader, properly
coded or tagged lists were rendered correctly, in an update or the new
version they are not. This is a bug of the AT and again, the correctly coded
or tagged content should not fail any type of compliance because of this.

Just as there are tools for QA that are mechanical, we must remember that
the AT tools are also mechanical. If there is a flaw in the way content is
being rendered and interpreted by AT, I agree with Birkir that we need to
lobby the AT developers for better and more consistent support.

Cheers, Karen