Categories
screenreader testing webaim yahoo

Learning How to Test with Screen Readers

Although accessibility checklists are important, testing for web accessibility requires more than that. Some testing requires tasks which can only be done by a human including testing with a screen reader. It’s best for a regular screen reader user to do the testing, but it’s also good for a developer or designer to do at least the basics (there was a big discussion on this last fall in Should Sighted Developers Use Screenreaders To Test Accessibility?).

Here are some good articles to help learn how to use a screen reader to test for web accessibility:

More from comments:

Categories
screenreader testing

Screen readers and Testing

Response to article by @vavroom Should Sighted Developers Use Screenreaders To Test Accessibility?
http://accessibility.net.nz/blog/should-sighted-developers-use-screenreaders-to-test-accessibility/

Good to test with screen reader, but best to have screenreader users themselves test a web site for accessibility.

Categories
alt captcha news screenreader socialmedia twitter webaim

Twitter Roundup – January

Wow, this first month of 2010 flew by! So much going on in the Twittersphere, as usual. Here’s a quick summary of some great articles mentioned in the Twitter accessibility community. Please comment with anything outstanding that I’ve missed!

Also, on a sad note, we recently mourned the loss of Jack Pickard; a huge loss in the web accessibility community. Jack was a great web accessibility expert and advocate.

Categories
articles screenreader survey visual

More on WebAIM’s Screenreader Survey

WebAIM’s Screen Reader Survey a few months ago (October 2009) sure drew a lot of attention, and for good reason. It is a much needed and well written survey, performed by one of the leading organizations in web accessibility, WebAIM. Here are some articles written in response to the survey. If you know any others, please leave a comment and let us know!

Related Articles

My Observations

Some of the more outstanding results of the survey I believe are:

  • 75% of respondents said they do NOT have JavaScript turned off (most had it on).
  • The most problematic items seem to be the same predictable items, unfortunately. The top 10 includes CAPTCHA, Flash, alternative text, forms, and headings.
  • 42% surveyed said they didn’t know ARIA Landmarks for navigation existed. I highly suspect this number will steadily decrease.
  • Although over 66% of users reported JAWS as their primary screen reader, almost half said that free or low-cost screen readers (such as NVDA or VoiceOver) are currently viable alternatives.
This post is sponsored by: Web hosting at Hosting.com
Categories
aria navigation screenreader

Screen readers and navigation

i navigate by headings when reading a long technical document or news items and essays that are large

i try to navigate by edit box when i can (using edit box navigation, i get the “donate” edit box before the Username edit box on the AccessibleTwitter sign-in/home page, which is a bit unexpected from a user’s point-of-regard)

on pages with multiple forms, since ARIA and the Role Module lack a “form” landmark (the closest thing is “search” – i logged a bug against ARIA 1.0 and the Role Module requesting “form” as a predefined role), i usually use either an AT-generated or a UA-generated list of form fields which is navigatable not just through use of the UpArrow and DownArrow keys, but by first letter of the labelling text

yes, accesskey is problematic with IE as there is no way to cascade ALT+Key so that a user can use the accesskey without conflicting with the UA’s chrome — but FireFox overcame this by using ALT+SHIFT+Key on the windows platform, and Opera has the most customizable accesskey options available anywhere…

my point of view on accesskey is that it does work under the right circumstances, and in those circumstances it is a DEFINITE time and energy saver when one can simply jump-to a particular form and/or form field using an accesskey — to me, the benefits outweigh the drawbacks, but that is simply my opinion, which is both philosophical and practical — or at least so i like to tell myself…

FYI, i’ve been working on accesskey replacement strategies:

1. general HTML A11y Task Force Access (Key) Replacement Wiki Page:
http://www.w3.org/WAI/PF/HTML/wiki/Access

2. Accesskey Replacement Requirements (approved by PFWG years ago):
http://www.w3.org/WAI/PF/HTML/wiki/Access/access_key_requirements

3. a plan to port the XHTML Access Module to a generic Access Element
to address navigation not only in structured, but in stacked, markup
langauages as well:
http://www.w3.org/WAI/PF/HTML/wiki/Access/element_versus_module

4. rob burns’ (robburns1 on twitter) Command & Event and Keyboard
Focus Module:
http://www.w3.org/WAI/PF/HTML/wiki/Access/command_and_event

the
worst offenders are forms inside tables? one has to use table mode to get oriented and check labelling, then switch to forms mode in order to interact with the form fields — aria will definitely help this, but what would help FAR more is if content developers actually abided by the newish verbiage in the HTML5 draft that explicitly bans the use of TABLE for layout or stylistic purposes