Screen Reader Testing Needed

Justin justin.obara at utoronto.ca
Wed Sep 10 13:25:20 UTC 2008


Hi Allison,

Thank you for all the information below. It looks like it will be  
quite helpful.

I'm really starting to get a nice library of resources.

Thanks
Justin
On 9-Sep-08, at 8:48 PM, Allison Bloodworth wrote:

> 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/20080910/26c3f33e/attachment.html>


More information about the fluid-work mailing list