Screen Reader Testing Needed
abloodworth at berkeley.edu
Wed Sep 10 00:48:39 UTC 2008
A few years ago as I was doing research on accessibility, I gathered
resources I found helpful here: http://tpo.berkeley.edu/resources/index.htm#accessibility
. One of my favorite articles on testing with screen readers was this
one: http://www.webaim.org/articles/screenreader_testing/. It has
links to the keyboard shortcuts for JAWS & Window Eyes (though I'm not
sure if they are now dated) and was where I learned you can use the
trial versions of these screen readers for 40 minutes every time you
re-boot your computer.
Also, on a somewhat separate but related topic, I've also been talking
with Mike Elledge about designing good screen reader and keyboard
interactions. Just designing, not coding (since I'm not coding :)). I
haven't found any real "guidelines" for designing good keyboard
interactions (e.g. are there standard interactions or key combinations
I should use), but there is definitely some good guidance on designing
for screen reader users. If anyone has other resources they'd like to
recommend on these topics, I'd love to hear about them.
A lot of these guidelines are things I've already internalized (and
maybe others will find them obvious), but I thought I'd list the
design (as opposed to markup) focused guidelines for folks as it's
always nice to have a reminder. :) They come from a couple of articles
on my Resources page above:
From: "Guidelines for Accessible and Usable Web Sites: Observing Users
Who Work With Screen Readers:" http://www.redish.net/content/papers/interactions.html
Guideline 1. Write for the web.
Guideline 4. For designers and developers of Web sites: Make the site
structure clear and obvious.
Guideline 6. Write "home page" as two words.
Guideline 7. Do not make up unusual names for products, services, or
elements of a Web site. Do not combine two or more words into one name.
Guideline 10. Include a "skip" link at the top of every Web page. Name
it "Skip to main content."
Guideline 11. Make links descriptive. Be sure that the link will be
useful by itself, with no surrounding text. Do not use "click here,"
"more," "answer," or other repetitive words or phrases as links.
Guideline 12. Start links with relevant keywords.
Guideline 13. Try not to have many links that start with the same word
Guideline 14. Start question headings with a keyword followed by the
question. (e.g. Literacy – What is it?)
Guideline 15. Pay attention to the wording on pages and be sure that
keywords that users would look up are actually on the page.
Guideline 16. Make sure that the keywords are not in images.
Guideline 20. Use anchor links when a page has several topics.
Guideline 22. Encourage authors to use many headings in their content
and to be sure that those headings are clear, meaningful, and parallel.
Guideline 24. Put the keyword at the beginning of the heading. If many
headings are about the same thing, differentiate them in meaningful
Guideline 25. Do not put a lot of text on the same page as a form.
Guideline 26. Do not put a form far down on the page or far to the
Guideline 28. In addition to checking your site with an automated tool
like Bobby or LIFT, listen to it with a screen reader.
Guideline 29. Do not put information between fields on a form.
Guideline 30. If the user has an option of filling out either of two
fields, and they are mutually exclusive, inform the user with the
label of the first field.
Guideline 31. Do not exclude labels from fields.
Guideline 32. Avoid making pages refresh.
From: "Usable Accessibility Group" Tutorial (created a group of i-
Schools students at UC Berkeley -- much more specific info is found
under the link to each point)):
4. Provide a "skip" link to bypass repetititve page content such as a
5. Make link names more informative than "click here"
6. Provide high color contrast for students with low-vision impairments
8. When designing a form, ensure that the prompt precedes the input
9. Segment long lists using structured and consistent headings
On Sep 9, 2008, at 1:20 PM, Daphne Ogle wrote:
> Hi all,
> We have some tasks in the design iteration to prepare for screen
> reader user testing. Mike has volunteered to prepare some user
> testing protocols for us for screen reader and keyboard users for our
> components. I wonder if the QA protocol ends up looking a lot like
> the user testing protocol?
> On Sep 9, 2008, at 11:51 AM, Justin wrote:
>> Hello Michael,
>> Thanks for the reply, please see my comments below
>> - Justin
>> On 9-Sep-08, at 2:19 PM, Michael S Elledge wrote:
>>> Hi Justin--
>>> I've found that the best approach is to go through a site as if you
>>> were a screen reader user, i.e., using common user commands,
>>> listening to page content and trying out functionality.
>>> I can put together a protocol for reviewing a page/component for you
>>> to try.
>> If you could send me a protocol that would be very helpful. My
>> concern right now is that I'm not actually using the screen reader
>> like a screen reader user would. A protocol for any of our components
>> on the daily build page would be good (build.fluidproject.org)
>>> In actual user testing, we ask screen reader users to perform the
>>> same tasks as sighted users.
>> I should look into this. I suppose I should do a preliminary pass to
>> test it first before getting a user to try it.
>>> Justin wrote:
>>>> As Fluid's components continue to develop and progress it would be
>>>> helpful to ensure that they are meeting the needs of those using
>>>> Screen Readers.
>>>> I am still learning about screen readers, and as such haven't been
>>>> able to properly test our components with them.
>>>> Any help with this would be greatly appreciated.
>>>> Also if you have any good learning resources that you would like
>>>> to share, please pass them along.
>>>> Thank You
>>>> fluid-work mailing list
>>>> fluid-work at fluidproject.org
>> fluid-work mailing list
>> fluid-work at fluidproject.org
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne at media.berkeley.edu
> cell (510)847-0308
> fluid-work mailing list
> fluid-work at fluidproject.org
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
abloodworth at berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work