E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Julius Charles Serrano
Date: Wed, Apr 10 2013 9:58PM
Subject: testing with JAWS and NVDA
No previous message | Next message →

Ohai everyone.

Apart from throwing your computer out the window, what would you do in a
situation wherein you're testing something, and it is accessible to NVDA
but not to JAWS?

Example: When you focus on a link, NVDA correctly reads it as a link,
but when you use JAWS, it only reads the link text as though it was just
plain text.

Kind regards.

Julius

--
Julius Charles Serrano
Accessibility Specialist
Catalyst IT Ltd
http://www.catalyst.net.nz
Mail: = EMAIL ADDRESS REMOVED =
Phone: +64 (4) 803-2436

From: Don Mauck
Date: Wed, Apr 10 2013 10:14PM
Subject: Re: testing with JAWS and NVDA
← Previous message | Next message →

What site are you on?

From: Karlen Communications
Date: Thu, Apr 11 2013 4:33AM
Subject: Re: testing with JAWS and NVDA
← Previous message | Next message →

We depend on the standards and make sure that the code or tagging is to the
standard. Even with a technology that might read things correctly when you
start a document or web page, the mechanical tool/screen reader or
Text-to-Speech may grow tired and read things incorrectly. We can't define
accessibility as being AT centric and we can't fail digital content if there
is a glitch or bug in the AT. This would mean testing every page against
every setting and version of both AT and browsers for "compliance."

I use AT and I do use it to test but if the code is right and the AT is
reading it incorrectly, this is not a failure of the coding or tagging or
the accessibility of a document, we need to be able to separate the quirks
of the AT from our testing and what we define is "accessible."

Is the coding or tagging correct for the content?

Cheers, Karen

From: Subhash Chhetri
Date: Thu, Apr 11 2013 5:32AM
Subject: Re: testing with JAWS and NVDA
← Previous message | Next message →

Yes Correct.

Here I share one of my experience that I came across:

Once one of my friends reported an issue that a particular link is
inaccessible with Tab Key with JAWS,

But client came with Screen Shot showing link is quite ok with tab.

After that we validate the issue in multiple systems, though the environment
was same, Result was quite shocking.
IN only one system, issue reproduced.

JAWS was reinstalled, even the PC was formatted, issue remained same in that
particular system.

So, whenever you test anything, do the same in multiple systems. Then only
come with final result.


Best regards,
Subhash Chhetri

From: Birkir R. Gunnarsson
Date: Thu, Apr 11 2013 5:39AM
Subject: Re: testing with JAWS and NVDA
← Previous message | Next message →

Can you post the page you are testing?
I am just curious in what situation this happened.
What is the Jaws verbosity setting (it should not make a difference of
course, but strange things do happen).

If this is a problem with one screen reader, I do try to get back to
the manufacturer with an explanation of the problem.
Of course, in most cases, it seems like a wasted effort, but when I do
have time (it happens), I do my best, I have even applied to become a
Jaws tester and am waiting on the reply, and I have filed a bug or two
with NVDA.
The most recent Jaws bug I noticed, for instance, is that Jaws (at
least Jaws 14 with IE9) stops automatically reading the
aria-describedby attribute on a field when verbosity is set to
"advanced". FS has confirmed the bug, at least in the context I
submitted it, and I hope to see a fix for it.

Web accessibility is complex and fascinating.
The standards and best practices help guide the authoring and create
consistency, to some degree, with the browsers, and a link between the
browsers and the Assistive Technology being used, but of course not
always 100%. There are both bugs and mistakes, and also standards
leave some room for interpretation and each assistive technology can
have slightly different take on accessibility based on what they
believe works best for the user.

Then there is the end users, how they interact with their assistive
technology, and to what extent they can take advantage of it and
understand how to use it, but that's a different thread altogether.
So, back to the original point, if you have time and think this is a
bug, definitely file it with the Assistive Technology vendor, feel
free to post it to the list if you are allowed to do so.
Cheers
-B

On 4/11/13, Karlen Communications < = EMAIL ADDRESS REMOVED = > wrote:
> We depend on the standards and make sure that the code or tagging is to the
> standard. Even with a technology that might read things correctly when you
> start a document or web page, the mechanical tool/screen reader or
> Text-to-Speech may grow tired and read things incorrectly. We can't define
> accessibility as being AT centric and we can't fail digital content if
> there
> is a glitch or bug in the AT. This would mean testing every page against
> every setting and version of both AT and browsers for "compliance."
>
> I use AT and I do use it to test but if the code is right and the AT is
> reading it incorrectly, this is not a failure of the coding or tagging or
> the accessibility of a document, we need to be able to separate the quirks
> of the AT from our testing and what we define is "accessible."
>
> Is the coding or tagging correct for the content?
>
> Cheers, Karen
>
>

From: Bryan Garaventa
Date: Thu, Apr 11 2013 8:55AM
Subject: Re: testing with JAWS and NVDA
← Previous message | Next message →

I'm sorry, I have to disagree.

Strict adherence to a particular standard cannot be used as an excuse for a
feature that is not accessible to screen reader users. I have a complex
example of this that I'll be sharing on Monday.

JAWS is the foremost screen reader as reported by the WebAim survey,
followed by NVDA, and deliberately not making something accessible when it's
known not to work in one or the other cuts out a significant percentage of
the market.

Regarding the link issue, that sounds like a role mapping issue relating to
an incorrect usage of ARIA, which I have seen before. This is actually quite
easy to correct.

Please share the page or code and it will be much clearer.

----- Original Message -----
From: "Karlen Communications" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, April 11, 2013 3:33 AM
Subject: Re: [WebAIM] testing with JAWS and NVDA


> We depend on the standards and make sure that the code or tagging is to
> the
> standard. Even with a technology that might read things correctly when you
> start a document or web page, the mechanical tool/screen reader or
> Text-to-Speech may grow tired and read things incorrectly. We can't define
> accessibility as being AT centric and we can't fail digital content if
> there
> is a glitch or bug in the AT. This would mean testing every page against
> every setting and version of both AT and browsers for "compliance."
>
> I use AT and I do use it to test but if the code is right and the AT is
> reading it incorrectly, this is not a failure of the coding or tagging or
> the accessibility of a document, we need to be able to separate the quirks
> of the AT from our testing and what we define is "accessible."
>
> Is the coding or tagging correct for the content?
>
> Cheers, Karen
>
>

From: Karlen Communications
Date: Thu, Apr 11 2013 9:47AM
Subject: Re: testing with JAWS and NVDA
← Previous message | Next message →

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

From: Steve Green
Date: Thu, Apr 11 2013 10:09AM
Subject: Re: testing with JAWS and NVDA
← Previous message | Next message →

While I am largely in agreement, it is worth noting that developers have always had to code around shortcomings in browsers, and it is arguable that it is no different to code around shortcomings in ATs.

Coding to standards is a start but it does not guarantee good accessibility, and we often recommend that changes are made to websites that are fully standards-compliant. However, we would not recommend a fix for one AT that has an adverse effect on others.

Steve Green
Test Partners Ltd

From: Julius Charles Serrano
Date: Sun, Apr 14 2013 12:46AM
Subject: Re: testing with JAWS and NVDA
← Previous message | No next message

Hi all.

Thanks very much for your ideas and comments. It is very interesting to
read the various opinions about AT and their varying behaviors which
affect accessibility. All your responses are valuable, and I
particularly find Bryan Garaventa's statements very interesting.

I am sorry I can't share the link as it is an internal client website.

Thanks again.

Julius