For years it’s felt like screen reader users have mainly used IE on the desktop in combination with the major screen readers Jaws by Freedom Scientific and WindowEyes by GW Micro. It’s not that other platforms don’t support screen readers (we have Orca on Linux, VoiceOver on Mac) it’s just that IE seems to have dominated.

As such what types of content and web technologies users can and can’t access has very much been driven by what the three software vendors Microsoft, Freedom Scientific and GW Micro have supported. This has made access to the open web a bit lopsided cutting down on choice for the end user, competition and by extension innovation. SVG is an example of a web technology that has possibly suffered by not being supported by IE and in turn by Jaws and WindowEyes.

What’s interesting to see in this year’s survey is that Jaws and WindowEyes – while still the most used – have some stiff competition at snapping at their heels from open source, free screen readers (NVDA and  SAToGo ) and VoiceOver which is available with Mac:

• JAWS 75.2%
• Window Eyes 23.5%
• VoiceOver 14.6%
• System Access or System Access To Go 22.3%
• NVDA 25.6%

While this year’s stats show little shift for Jaws and WindowEyes usage overall there is a significant leap forward for NVDA (NonVisual Desktop Access) and VoiceOver:

Of the 1121 respondents, 74% use JAWS, 23% use Window-Eyes, 8% use NVDA, and 6% use VoiceOver. While several other screen readers were reported, these were the most prominently reported.

The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile.

This could also explain the increase of screen reader users on mobile reported this year with 53% of survey respondents with disabilities confirming they use a screen reader on a mobile device. This is up from 12% last year (although last year’s survey doesn’t distinguish disabled from non-disabled users).

I wonder how much this is to do with the ‘iPhone Factor’ but also can’t help thinking that social networking has done for the mobile web what Kylie Minogue did for Agent Provocateur – everybody wants some. And for me at least 2009 feels like the year that we all sat up and paid attention to the potential of mobile for people with disabilities.

We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into. On desktop we have IAccessible2, MSAA and UI Automation (amongst others) but on mobile users are tied into one platform often only supporting one browser (such as iPhone, Blackberry RIM and others) so while desktop has opened up we find ourselves in a 1990′s type impasse with users left with little room to choose on mobile. Opera works well with VoiceOver but we have no way of telling if it works on the iPhone as it’s not supported. My hope is that with more users there’ll be more momentum behind breaking this stand off and opening up the market and ultimately giving users not only choice but portability between platforms.

It’s good to also see the free, open source NVDA on the up. They’ve worked hard to include WAI-ARIA support and are becoming a key tool for web developers when testing. The Jaws demo version used to be popular among developers but with the license becoming less developer friendly NVDA is becoming a safer option.

It’s early days but the rise of VoiceOver and NVDA combined with alternative browsers such as Opera, Safari and Firefox may break the hold that screen reader giants Jaws and WindowEyes have over the market, helping to open up competition and with it how fast screen readers innovate in supporting new technologies such as HTML5, SVG and so on. This will be a win all round for both users and developers.

Update 12 November, 2009

Jared’s presentation The Legend of the Typical Screen Reader User summarises many of the points above. He also includes quotes from screen reader users at the end in response to the question “What suggestions do you have for developers/manufacturers of screen readers?” which he mentions in his comments below.

Mobile accessibility resources:

• Fluid mobile accessibility wiki
• Open Letter Initiative

Before you get started, if you’re not already familiar with keyboard access in Opera, it’s worth having a read of Opera accessibility: where we’re at. I’ll cover what you need to know here but article is good for background information.

Huge thanks go out to Victor Tsaran over at Yahoo! who gave me some great feedback while I was testing as well as Jon Gibbons (Dotjay) who rustled up an accessible table of VoiceOver commands and Alastair Campbell who pointed me to his overview of VoiceOver.

Setting up keyboard access on OSX

Mac is odd as it requires that you switch on full keyboard access and optimise it for access technology before you can truly get started. Fortunately however it’s pretty simple to set up:

1. Open System Preferences.
2. Click Keyboard and Mouse.
3. Select the Keyboard shortcuts tab.
4. Ensure the “Turn full keyboard access on or off” option is checked.

Next:

1. Open Universal Access within System Preferences.
2. Check “Enable access for assistive devices”.

System Preferences in Mac with Keyboard shortcuts selected and "Turn full keyboard access on or off" highlighted

Setting up keyboard access in Opera

Once Mac is set up you’ll then need to check Opera is ready for keyboard access:

1. Choose Opera > Preferences.
2. Click Advanced.
3. Select Shortcuts in the list of settings.
4. Check the “Enable single-key shortcuts” checkbox.

Basic VoiceOver keyboard commands

With keyboard access set up in Mac and Opera you’re ready to go. These are the basic VoiceOver commands you need to start interacting with the browser chrome and HTML content. Note that “Voiceover keys” (or VO), means the Ctrl and Option keys pressed together.

1. Toggle VoiceOver on or off - Cmd + F5.
2. Navigate around the chrome – VO + Cmd + Shift and Arrow keys.
3. Interact the HTML content – VO + Shift + down arrow (↓).
4. Interact with the browser chrome – VO + Shift + up arrow (↑).
5. Navigate content (Spatial Navigation, see below) – Shift+ Up, Down, Left or Right arrow.
6. Tab through form elements – TAB / Shift+TAB.

Basic Opera keyboard commands

When using Opera you can do more than just tab linearly around the page as you would in other browsers. The TAB key only picks up form elements allowing you quick and easy access to forms by jumping over other content. To access all content on a web page you can then use the following:

• Spatial Navigation – By holding down Shift + left, up, right and down arrows (← ↑ → ↓), you can move up down, left right and across the page. The pus side of this is that you don’t have to laboriously tab though linear content.
• Single key shortcuts – One you have enabled Single Key Shortcuts (see ‘Setting up keyboard access in Opera’ above) you can simply use ‘S’ and ‘W’ to move forward and backwards through headings and ‘A’ and ‘Q’ to do the same with links. Check out the navigating headings, links, page elements, images, tabs and zooming section below for more details.

The important thing to remember is that while VoiceOver has it’s own keyboard commands for accessing headings and links often navigation works better if  Opera Single Key Shortcuts and Spatial Navigation is used. Single key shortcuts can also be customised either via the Preferences (In  Advanced > Shortcuts > Keyboard setup then Edit) or by changing the .ini files.

Preferences

Before you start browsing you’ll most likely want to customise how you browse using Preferences.  Using VoiceOver you should be able to configure content, security, shortcuts, tabs etc using the following commands:

• Open Preferences – Cmd+Comma (,).
• Tab through all content (including switching between tabs) –  Ctrl+Alt+ Right, Left, Up or Down arrow keys.
• To interact with a list –  Shift+Ctrl+Alt+Down.
• Cycle through lists – Arrow keys.
• Access  highlighted list item -  Ctrl+Alt+Right, Left, Up or Down arrow keys.

The Preferences screen showing Shortcuts highlighted in the Advanced tab with Enable Single Key Shortcuts selected.

Reading text

You can read what you like when you like using the following keyboard commands:

• Read content – VO + A.
• Stop reading - Ctrl.
• Navigate through paragraphs, headings, and elements – Single key shortcut ‘D’ (forward) or ‘E’ (backward).

Navigating headings, links, page elements, images, tabs and zooming

As mentioned above all elements can be accessed using either Spatial Navigation (Shift+Arrow keys) or single key shortcuts.

What follows is a list of main keyboard shortcuts. Where I have said “Navigate to get VO feedback” it means the function can be carried out but VoiceOver does not give feedback. Instead you need to start navigating in order to hear feedback.

I’m not familiar enough with VoiceOver as a technology but I’m told by our engineers that occasionally things lack feedback because it is hard to see what should be spoken and can be recognised. For example VoiceOver seems to have no concept of zoom level for instance.

I wonder also if this is because VoiceOver has been built with Safari in mind. Reading through the documentation you certainly get that impression. That said there is definitely more fine-tuning that we want to do our end.

Forms

As mentioned briefly above navigating forms on web pages is done using the Tab key.

• Move forwards/backward through form elements – Tab / Shift+Tab
• Select – Space bar
• Activate – Enter

Item List Chooser

The Item List Chooser in VoiceOver literally lists – in a keyboard navigable popup – all items available in a page or via the chrome. This is great if you want to get an overview of everything that’s going on.

Everything is listed alphabetically and by typing the first letter or more you’ll automatically get taken to where you want. If you’re a developer this is a good way of seeing what is and what isn’t accessible.

• List items in a page or in the chrome – VO + I
• Navigate the lists – Arrow keys.
• Escape – ESC
• Return to the chrome – VO + Shift + up arrow (↑)
• Return to HTML content -  VO+Shift+down arrow (↓)

WAI-ARIA

While Opera is working on WAI-ARIA support I haven’t found much information regarding VoiceOver support of  WAI-ARIA. VoiceOver is not listed on the Codetalks ARIA support page however Steve Faulkner has done some ARIA role tests on MAC with Safari 4 beta, Firefox 3 (minefield) and  Opera 10 Alpha and results show that 14 or 50 ARIA roles are exposed on Mac (Firefox exposes 0 and Safari exposes 15).

Update 30 July, 09 – Alex Jurgensen has very kindly pointed out a set of ARIA test cases on Codetalks that cover VoiceOver. This gives a good overview of where VoiceOver is at however Opera is yet to be added.

It’s early days for Opera and WAI-ARIA support so this is a section I will return to soon rather than give too much time to now.

Known quirks and feedback

You should be able to comfortably navigate most content in web pages if you are familiar with Opera’s keyboard navigation setup and shortcuts.

There are some areas of the chrome that you can’t reach however there are keyboard shortcuts to access all the main options and features you should need. I did find also that at times navigating out of HTML content was sticky so I’d switch to using VO + Shift + Cmd + Up arrow and it would take me up to a toolbar.

We are obviously always looking to improve on what we have so if you have feedback or questions please leave a comment and I’ll answer as best I can.

Summary of keyboard shortcuts

Below is a list of the keyboard commands I’ve referenced in this article. I’ll be adding in further comments based on feedback where necessary.

Links and things

• Opera accessibility – where we’re at.
• Keyboard shortcuts in Opera – comprehensive overview on how to use Opera via just the keyboard.
• VoiceOver commands (PDF) – Apple’s overview of VoiceOver commands presented as you’d see the commands on a keyboard.
• VoiceOver commands – brought to you by Jon Gibbons in an accessible data table.
• VoiceOver 1: Basics – from Alastair Campbell.

The W3C describes SVG is a relatively simple way to generate graphics on a web page using markup:

SVG is a platform for two-dimensional graphics. It has two parts: an XML-based file format and a programming API for graphical applications. Key features include shapes, text and embedded raster graphics, with many different painting styles. It supports scripting through languages such as ECMAScript and has comprehensive support for animation.

SVG is supported in all modern browsers – with the exception of Internet Explorer – including most mobile browsers making it an excellent cross platform bit of bling. Even the lack of support in IE could be addressed soon not by Microsoft itself but by Google who are billed to give a keynote at the SVG Open in October on their SVG for IE drop-in library. This could boost the popularity of SVG given that to date IE has been one of the biggest things holding it back.

Update 22 August 2009: Announcement about Google’s 60K library to bring SVG, SMIL, video, audio to IE.

The real bonus of SVG however is it’s scalability, integration with web standards, re-usability and ability to manipulate objects all of which lend SVG to being a robust – and crucially – accessible alternative to other image based formats such as GIF, PNG or JPEG.

SVG graphics can be scaled and resized without any of the blurring or pixellation that you see on traditional images. Scaling is important to users with low vision who enlarge text in the browser or rely on assistive technologies such as tactile graphic devices (which typically have a very low resolution) and screen magnifiers. So if you want to have images of text as headings and not worry about these becoming blurred and unreadable you can. As the image below shows, the enlarged PNG is pixellated whereas the SVG equivalent is smooth and crisp.

Comparison of PNG and SVG enlargements taken from Accessibility Features of SVG by Charles McCathieNevile and Marja-Riitta Koivunen

XML, being a text based language, also lends SVG to better accessibility than current headline grabbers such as HTML5 canvas which lacks an accessibility API or hooks for screen readers. While the WHAT-WG currently recommend a fallback – a draconian circa 1999 HTML alternative that confines screen reader users to a disability ghetto – they are working on a “built in” rather than “bolt on” approach asking for input from the accessibility community for viable solutions to make canvas accessible. Bruce Lawson has the lowdown on SVG versus canvas in his post  Canvas, accessibility and SVG.

SVG and screen readers

While SVG supports many of the accessibility guidelines that we see in WCAG 2.0 and is supported by all modern browsers except IE, there is one drawback: screen readers do not handle SVG well.

It’s hard to say why. As Bruce Lawson pointed out it may be because “big screen readers have traditionally sat on top of Internet Explorer”. I think it may also be because screen reader vendors have an awful lot to keep abreast of out there with regards to browser compatibility, emerging technologies such as ARIA, developments in HTML5 as well as compatibility with software such as MS Office, Open Office, Flash, PDF etc. Google’s promise of fixing SVG in IE should have some positive knock on effects – or at least let’s hope.

Screen readers not being able to handle SVG well is no reason to not make your SVG screen reader ready however. As always you want to be thinking about future proofing so as to avoid any pesky and costly retrofits at a later date.

Title and descriptions

The title and desc elements can be added to any graphic to provide a fallback for screen readers. These can be added to parts of the graphic – hierarchically – or the graphic as a whole. Both title and desc can be used together with the former acting as the title of the graphic and the latter as as expanded explanation (from what I’ve understood anyway). If the image above of the tigers was created in SVG you’d code it as follows:

<?xml version="1.0"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450"
xmlns="http://www.w3.org/2000/svg"  xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Tiger's head</title> <desc>A slinky SVG tiger</desc>
........
</svg>

According to the spec however the title element in SVG may behave a little differently to how the title attribute behaves in HTML:

Each container element or graphics element in an SVG drawing can supply a ‘desc’ and/or a ‘title’ description string where the description is text-only. When the current SVG document fragment is rendered as SVG on visual media, ‘desc’ and ‘title’ elements are not rendered as part of the graphics. User agents may, however, for example, display the ‘title’ element as a tooltip, as the pointing device moves over particular elements. Alternate presentations are possible, both visual and aural, which display the ‘desc’ and ‘title’ elements but do not display ‘path’ elements or other graphics elements. This is readily achieved by using a different (perhaps user) style sheet. For deep hierarchies, and for following ‘use’ element references, it is sometimes desirable to allow the user to control how deep they drill down into descriptive text.

While desc is not displayed (in accordance to the spec) it is up to the browser to decide how to render the  title element in SVG. In other words it can either be displayed as a ‘tooltip’ or not. Using Opera 10 Beta 2  title is shown as a ‘tooltip’, but neither Safari 4.01 Firefox 3 display the ‘tooltip’.

The closet match to the behavior of the title attribute in HTML in SVG is xlink:title.

The title attribute shall be used to describe the meaning of a link or resource in a human-readable fashion, along the same lines as the role or arcrole attribute. A value is optional; if a value is supplied, it shall contain a string that describes the resource. In general it is preferable to use a ‘title’ child element rather than a ‘title’ attribute. The use of this information is highly dependent on the type of processing being done. It may be used, for example, to make titles available to applications used by visually impaired users, or to create a table of links, or to present help text that appears when a user lets a mouse pointer hover over a starting resource.

A link with a title attribute in HTML would look like this:

<a href="http://www.mysite.com" title="My super funky site">visit my site</a>

Where as a link in SVG would look like this:

<a xlink:href="http://www.mysite.com" xlink:title="My super funky site"><text x="20" y="20">visit my site</text></a>

In the above the x and y value are the co-ordinates where the text is placed on the canvas. To ensure this works you have to declare the XLink namespace in the document, most commonly in the SVG root element.

One important thing to note is that the ‘a’ element can be wrapped around elements in SVG, a little like block level linking in HTML5. This is a great feature as it allows for a larger clickable area for those that need it and you can wrap as many components in the link – let’s say a graphic with accompanying text – as you like.

Hierarchy

Just as you would give an HTML page a hierarchical order the same is true of SVG. This allows a non-sighted user to build a mental map of the graphic and is founded on WCAG 1.3.2 Meaningful sequence.

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

Expanding on the tiger image above and adding in all four images into one would mean the code looked as follows:

<?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450"
xmlns="http://www.w3.org/2000/svg"  xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Tigers</title> <desc>Drab PNG tigers and slinky SVG tigers</desc>
<!-- add graphic content here, and so on for the other components-->
<g id="Tigera"> <title>Tiger A</title> <desc>A small tiger  using PNG</desc> </g>
<g id="Tigerb"> <title>Tiger B</title> <desc>A small tiger using PNG</desc> </g>
<g id="Tigerc"> <title>Tiger C</title> <desc>A large tiger using PNG</desc> </g>
<g id="Tigerd"> <title>Tiger D</title> <desc>A large tiger using SVG</desc> </g>
</svg>

You’ll notice in the above that the ‘g’ element is used to structure the document.  This is basically a container element that is used to group related graphics. ‘g’ elements can also appear within ‘g’ elements.

Grouping constructs, when used in conjunction with the ‘desc’ and ‘title’ elements, provide information about document structure and semantics. Documents that are rich in structure may be rendered graphically, as speech, or as braille, and thus promote accessibility.

Colour

The basic rule of accessible colour apply to SVG just as they would any other image. In other words don’t rely on colour alone to convey meaning or use colour that lacks contrast. This falls in line with WCAG 2.0:

1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

and

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

Mark up and CSS

Again familiar rules that apply to HTML and CSS also apply to SVG:

• Ensure your SVG validates to SVG RelaxNG grammar however some discussions suggest to do so without the doctype.
• Separate structure from presentation.
• Use text for text and not graphics.
• Provide as much structure and alternatives as possible using the g, title and desc.
• Style text using fonts not images.
• Use ‘xml:lang‘ to identify the natural language of content and changes in natural language. This ensures that textual content can be spell-checked, or converted to speech.

WAI-ARIA

ARIA describes how to add semantics and other metadata to HTML content in order to make user interface controls and dynamic content more accessible. In principle this is also applicable SVG and as such SVG 1.2 recommends ARIA for adding in accessibility hooks for screen readers via the ‘role’ attribute.

The ‘role’ attribute assigns one or more role values to an element which in turn can get fed back to a screen reader. ARIA 1.0 is currently in Last Call (the stage before it becomes a W3C Recommendation) and is expected to be published soon. While the SVG 1.2 specification recommends using roles, ARIA 1.0 itself is not massively focused on SVG. According to the Protocols and Formats Working Group however SVG will feature more in ARIA 2.0 (along with extensibility, live regions and HTML5 support).  Erik Dahlstrom, co-chair of the SVG Working Group, has provided feedback around SVG and ARIA including comments on managing focus, accessible name calculation,  navigation and more.

While it is clear there is a lot of work to be done the fact that ARIA roles can be used is a positive step forward as it acts as a bridge where screen reader support falls short.  Jaws, WindowEyes, NVDA, FireVox and Orca are all adding support for ARIA as is IE, FireVox, Opera and Safari (Codetalks has a list of who supports ARIA) so if thinking about adding ARIA to your SVG now is clearly a wise move.

So just how accessible is SVG?

Clearly a lot of work needs to be done to get SVG accessibility ready for screen readers. Some hooks are there however the real work is yet to come both from screen reader vendors as well as the specification writers. What’s reassuring is that both the ARIA and SVG camps recognise this and there is talk of SVG having a bigger focus in ARIA 2.0.

Putting screen readers aside there are clear benefits to SVG for screen magnification users with it being scalable, standards compliant and able to provide block level linking. The standards aspect of this is important as it means that you can use XSLT to transform SVG into HTML – readable by all assistive technology.

Accessible SVG has a potential – despite it being early days – as a useful alternative for canvas and other image formats. Who knows, with possible IE support on the horizon and more of a focus in Aria 2.0 perhaps screen reader vendors will step up efforts to support SVG. If they do as have a really robust technology out there to add to the developers toolbox.

For more check out:

• David Storey, Doug Schepers and Mathew Smith on Twitter.
• Accessibility features of SVG Charles McCathieNevile and Marja-Riitta Koivunen.
• Scalable Vector Graphics (SVG) Tiny 1.2 Specification from the W3C.
• Inkscape – an Open Source vector graphics editor, with capabilities similar to Illustrator, CorelDraw, or Xara X, using the W3C standard Scalable Vector Graphics (SVG) file format.
• Accessible Rich Internet Applications (WAI-ARIA) 1.0

This is not the case now though as browsers, screen readers, guidelines and technology has moved on and in many ways is catching up with one another. What follows are some tips to get you started when setting up a screen reader testing environment.

Why test with screen readers

• WCAG 2.0 and JavaScript: Where WCAG 1.0 had a blanket ban on JavaScript WCAG 2.0 now allows it providing it’s accessible to assistive technologies, or in WCAG 2.0 talk accessibility supported.
• WAI-ARIA: Screen readers can in fact handle most uses of JavaScript. It’s when they encounter areas of a page that update without full page refreshes or encounter functionality that is mouse orientated such as sliders, drag and drop or collapsible menus that they start to stumble. WAI-ARIA is a solution to help fix that by hooking into HTML to making it speak to screen readers. Gez Lemon’s Introduction to WAI ARIA, also available in Spanish, French and German, gives a good overview of what ARIA is.
• Browser support for WAI-ARIA: Varying levels of support can be found in Opera 9.5, Firefox, Safari and IE8.
• Screen reader support for WAI-ARIA: Screen readers are also catching up with varying levels of support in Jaws, WindowEyes, NVDA and Orca.
• JavaScript library support for WAI-ARIA: The following libraries all have varying levels of support: Dojo from IBM, YUI! and JQuery.

Set up a sandbox

Whether on Mac or PC you want to set up a screen reader testing sandbox. This means you can isolate glitches with installs as well as crashes and reboots. If you’re on a Mac there is more need for a sandbox as screen readers tend to be built for Windows. There’s plenty of virtualization software out there to help you do this including Parallels, VMWare, Virtual PC and so on.

Test with a variety of screen readers

Next you need to find screen readers that support WAI-ARIA. It’s not practical to buy every screen reader on the market although it is advisable to get what you can. If budgets are low there are plenty of free options available to you:

• Jaws from Freedom Scientific: designed for Windows the free demo allows for you to test for 40 minutes at a time before rebooting.
• WindowEyes, GW Micro: a fully functional demo is available for Windows but times out after 30 minutes.
• NVDA, NV Access: again just for Windows and only works with Firefox however it is available in full for free.
• Firevox: available in full for free on Windows and Mac but only works with Firevox.
• Orca: available on Linux, free and open source.
• Fangs: this screen reader emulator  is a Mozilla Firefox extension that displays a text representation of a web page similar to how a screen reader would read it.
• Thunder: available for Vista or XP.

Configuring screen readers

Screen readers are designed for the non-sighted user so you may want to set preferences to disable or change what you don’t find useful. For example I always switch off automatic page scroll in Jaws as I don’t want the page to scroll in line with the content being read out. You may also want to disable features that have the screen reader start up automatically as you boot your system up.

You may also find it useful to configure your screen reader keyboard shortcuts so that they are all the same in each one. That way you don’t have to remember one thing for Jaws and another for NVDA.This can be especially useful with regards to shortcuts for switching the virtual buffer on and off.

One final tip is to take a snapshot of everything once it is installed, this means you have it at hand to revert back to should anything go wrong. This can be done at various different stages throughout the set up on the sanbox.

Install browsers

Ensure that you have all the browsers that support ARIA installed on your machine (see above).You really should be testing across browsers just as you would in any development process.Note that while Opera is building in WAI-ARIA support that it works best with a screen reader on Mac with Windows to follow.

Testing advice

• Get comfortable with a screen reader first: finding your way round using a screen reader can be a tricky process. I’d recommend never diving in and testing unless you’ve spent some time just browsing the web in general and getting familiar with the environment. One really good trick is to spend an afternoon, day or a week browsing the web with just a screen reader with the monitor and mouse switched off. This is the ultimate crash course and once you’ve done it you’ll have a much better understanding of the types of challenges people face when browsing.
• Use real users: ultimately real users will reveal much more than just you testing or even just one genuine screen reader user testing. Use any screen reader users in-house you may have but also make sure you test with regular users. Often screen reader users within a development team are power users so mixing it up a bit with regular users is important. Never assume you know what the best solution is.
• Switch off the monitor: so often it’s not the technical accessibility that is a problem but how easy it is to follow and discover information. Simply put is what the user hears making sense? Have you described roles, states, properties and live regions appropriately? Do you need to teak the text on the page to make it clearer what the page is doing?
• Disable your mouse: check that all widgets and functionality can be accessed and triggered using only the keyboard just as you would if accessing desktop widgets. Check that you can use either shift or arrow keys to get focus onto elements and manipulate them. For example tab onto a slider then use the arrow keys to move the slider back and forth.
• ARIA test cases: Before you start testing make sure you know what support there is for the ARIA being tested. The best plac to look for this is the ARIA test cases page on Codetalks.

References and resources