Screen Reader Testing Needed

Allison Bloodworth abloodworth at berkeley.edu
Wed Sep 10 00:48:39 UTC 2008


Hi Justin,

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  
or phrase.
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  
ways.
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  
right.
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  
navigation menu
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  
selector
9. Segment long lists using structured and consistent headings

Cheers,
Allison

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?
>
> -Daphne
>
> 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  
>> biggest
>> 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.
>>
>>>
>>>
>>> Mike
>>>
>>> Justin wrote:
>>>> Hello,
>>>>
>>>> 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
>>>> Justin
>>>> _______________________________________________
>>>> fluid-work mailing list
>>>> fluid-work at fluidproject.org
>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>
>>>>
>>>>
>>> <elledge.vcf>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> 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
> http://fluidproject.org/mailman/listinfo/fluid-work

Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080909/8f945aed/attachment.html>


More information about the fluid-work mailing list