Screen Reader Testing Needed
justin.obara at utoronto.ca
Wed Sep 10 13:25:20 UTC 2008
Thank you for all the information below. It looks like it will be
I'm really starting to get a nice library of resources.
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
> 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
> 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
> 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
>>>> 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
>>> 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
> 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...
More information about the fluid-work