C# – Accessibility with screen readers (ex. Jaws)

accessibilityajaxcjaws-screen-readernet

A colleague of mine came to me with a problem on one of his projects. Unable to help him, due to my lack of experience with screen readers and the technology, I turn to you, the proud and mighty mass of SO users.

Summary for the TLDR-folks:
Our Grids in UpdatePanels aren't working in screen-readers. Might be something with the AJAX toolkit?

Can anyone help or provide suggestions on what steps we might be able to take next?

Here is what I received from my colleague (the emphasis is mine, not his, hoping to improve scannability):

I’m presently working on accessibility
and I ran into some issues when it
came to pages using Ajax. I used
screen readers to test the page’s
accessibility. A screen reader
attempts to identify or interpret
what’s being displayed on the screen
with the help of audio
(text-to-speech) and then transmits
the information to the user. This is
very helpful for people who are blind,
visually impaired, illiterate or
learning disabled. Here’s a brief
summary of how a screen reader works.
The screen reader takes a snapshot of
the web page and places the content in
a virtual buffer. The screen reader
uses the virtual buffer to allow the
user to navigate through the content.
If the content is changed with
scripting, then this needs to be
relayed to the screen reader. Without
a mechanism to discover what has
changed, a screen reader user might
not be notified that the content has
changed at all, or only be notified
that the content has been changed, but
will be required to read the whole
document to discover exactly what has
changed. For testing, I used two
types of screen readers, Access To Go
3.0.76 and Jaws 10.0.

My findings while testing were that
on the pages that have a gridview
within an update panel, a typical
search page for example, the screen
reader would read, as per usual, all
the information on the page before
searching (search criteria). Upon
pressing the search button, our
gridview containing the column headers
and the result set is generated. The
screen reader does not get the
information that would inform it that
new content has been written to the
page therefore silence is heard. A
technique has been recommended by a
Microsoft employee that involves
inserting a hidden IFrame within the
update panel that would trigger the
screen reader to navigate to the
updated content and read it. The web
site explains how to achieve
accessibility only with the
UpdatePanel control. I’ve tested this
technique and had no success in making
it work. It renders an iframe but the
screen reader still doesn’t know about
an update to the page.

Our AjaxControlToolKit version is
1.0.11119.0 and does not provide ARIA (Accessible Rich Internet
Applications) live region markup. Live
regions indicate that content changes
may occur without the element having
focus and provides the assistive
technology information on how to
process those content updates. The W3C
has recommended a semantic on how to
organize the content of a page,
basically giving a role to every
element on the page so that assistive
technologies can convey the
appropriate information to the user.
I’m not sure what this implies in
terms of where we are technologically.

Best Answer

AJAX webpages are not a problem for screen-readers, at least for Jaws, and that is about 2 years ago (I developed some web apps with lots of AJAX which worked great with Jaws).

Anyway, you should use good screen CSS layout, and HTML anchors for better accessibility (title, alt, tabindex, label).

Anyway, if you really worry about accessibility, you should load everything through an iframe and use a callback to update the parent (a little <script> tag which updates the parent container DIV with the iframe content). Have also a look at PORK.Iframe (http://schizofreend.nl/Pork.Iframe).

EDIT: There's good stuff there: Sitepoint article about AJAX and screenreaders

Related Solutions

Html – SPAN tag ignored by JAWS screen Reader

I would first want to know why you are using a span element and not a standard a href element? What is it you are wanting to achieve? It may help if you can provide more context\code.

I've just tried this and am getting the same issue; whilst I can arrow through the document and have a span read out to me, I cannot then tab to it and have it read out.

Using something instead like

<a href="#" onclick="javascript: return false;">Whatever</a>

works fine.

There are additional problems around using the tabindex attribute, specifally for keyboard users. On a page that users the tabindex attribute, the tab focus order will first of all go through all of the elements with tabindex specified, and then run through all the elements without it, in source code order.

A good general rule is to either use tabindex for all keyboard accessible elements, or for none of them, to get around this problem.

I realise in this case, you are likely using tabindex to just provide keyboard accessibility for this one item, so this issue may be irrelavant if you use the a href approach mentioned, but I wanted to mention it for completeness

Javascript – Screen readers and Javascript

You can test this without needing to know how screen readers parse the DOM. I offer this answer primarily because you haven't offered any code to test ("some stuff to some of the pages" is not code to test) and your example doesn't provide enough context.

Install NVDA, a free screen reader for Windows.
If on a Mac, turn on VoiceOver.
If on Ubuntu / Gnome, install Orca
Download and run a trial of JAWS.
If on iOS, turn on VoiceOver.
If on Android, turn on TalkBack.
Heck, try Narrator on Windows.

There are plenty of tutorials to get you up and running. Here are a couple:

A video overview of NVDA.
Get a list of keyboard shortcuts for many screen readers.

Then, if you find that your script modifies the DOM after the screen reader has already parsed it, explore ARIA live regions and then look at browser support.

Finally, your example above about detecting if script is enabled doesn't actually need script to work if you use the <noscript> element:

<noscript>
 <p>
 Please enable JavaScript to receive this content.
 </p>
</noscript>

If a browser has script enabled, this will not render (which is good). This does not, however, address cases where the script block you want to show fails for other reasons (network lag, bugs, etc). More on <noscript>

Since you say you are "creating a website for a reading service for the blind and visually impaired" the onus is really on you to learn the tools and how to test with them.

Best Answer

Related Solutions

Html – SPAN tag ignored by JAWS screen Reader

Javascript – Screen readers and Javascript

Related Topic