Blueleaf Developer, Simon Pioli, recently attended the popular UpFront conference - you may remember his write up. Simon was particularly inspired by one of the talks and he wanted to expand on this and share a little more depth with you loyal Browse readers.
Over to Simon...
The talk I'd like to expand on was by Derek Featherstone who runs Simply Accessible, an agency that offers consulting and training on creating accessible websites.
The premise of Derek's talk was that accessibility is about more than making sure your markup is compliant and usable to screen reader users and that getting it right really starts from the design.
I'm going to break some of his specific points down into sections:
Visually Impaired Users
The most common way that many of us make our websites accessible to visually impaired users is by ensuring that blind people can use them with screen reader software and a keyboard. This means making sure that all the markup is ordered in a logical way and has all the right attributes (including ARIA meta) and ensuring key elements aren’t hidden entirely with CSS.
While doing this is great, and really helps a great number of people, there is a huge range of different disabilities that fall in the category of ‘visually impaired’. Partially sighted people may not use a screen reader, rather they use tools that zoom part of the screen massively, which will obscure other parts of the page.
This form is quite good. Most of the form fields can be seen in the same space as the labels.
However, as you can see the form navigation does need a little work as you can’t see the 'Next' button in the same view as the 'Previous' button, they both look similar in terms of colour, font size and weight.
The Straw Test
This is a quick and dirty technique which simulates how visually impaired users may see their screen. I’ll let Derek explain in this 2 minute clip.
You may have also noticed the difference in the position and hierarchy of the buttons at the end of the forms. This is part of a ‘pattern of use’ which means that the flow of the form makes sense when you’re zoomed in.
On the first iteration, the first button you’d come to after scrolling back and forth left-right is the ‘Quit’ button, which is just as important as the other buttons… Erm, what?
On the second iteration, the first button you’d come to is the ‘Next’ button which is given a lot more prominence than the other buttons.
This is the easy bit, right? Wrong. There’s plenty of data that supports the fact that most users use the latest or previous version of a web browser. This is because they’re free and these days the vast majority update themselves. Screen readers are very different. This is partly because they’re incredibly expensive  but also because a lot of users don’t see the benefits associated with those costs.
Derek cited an example of testing with a user who has JAWS 10 (at time of writing, the current version is 17). In terms of age, this version was released during the IE6 era!
If you’ve never witnessed an experienced screen reader user using their computer, you should, it’s incredible. They tend to accelerate the pace of the software from the default 180 WPM (words per minute) up to a dizzying pace of 300 WPM. At the end of the the 3 years I spent at university with a partially sighted friend, I still couldn’t follow what he was doing without watching the screen!
This extreme pace means that users ‘skim’ content in a similar manner in which sighted users tend to. This means that some elements are often missed despite being ordered appropriately and sounding OK at the pedestrian default.
User testing with a good selection of real screen reader users is highly recommended to get this right.
 JAWS costs £659 then £125 - 180 for upgrade agreements.
The Viewport isn’t a proxy for anything
In other words you cannot assert any other information about the user’s device or browser from the viewport dimensions alone. For example, this common assertion:
small viewport == mobile
In the context of visual accessibility this is because a lot of highly impaired or total-loss users run their computers without a screen attached at all. This is called ‘headless mode’. Windows does some funky things in headless mode. Firstly, it changes to a portrait aspect ratio and secondly, users have absolutely no idea what the relative size of the application windows are (and of course, they don’t care), so they end up with viewport sizes all over place. 320x200 and 100x50 were 2 fairly extreme examples that Derek showed us. An easy way to cover this off is to test smaller viewport sizes with a keyboard. Don’t just presume that because the viewport is small, the device is small or ‘mobile’ AND that it has a touch screen.
Ever since we started making fluid and responsive websites I’ve resisted using terms such as ‘mobile’, ‘tablet’, ‘desktop’ etc when I'm working on a particular view of a site, preferring to use terms such as ’small viewport’, ‘large viewport’ etc. I’ve never seen how you can make such a direct assumption from a single piece of information and this is a good reason why you shouldn’t.
Disability is a usability amplifier
To be effective and comprehensive, accessibility must start from the design of the site. If you make a usability improvement that makes a process 2x as easy for a non-disabled user to complete, it’s probably closer to a 10x improvement for an impaired user.
Take the example form we looked at in the first section. If that’s better designed to make the options vertical, it’s an improvement for both small-screen users and users who use extreme zoom.
Long and complex forms are difficult for everyone to use, not just disabled users. Breaking them down into sections, allowing people to save progress and optimising the field types and validation helps everyone but particularly those with motor impairments who find it harder to tackle a long process in one go.
Tests: there’s a few fairly simple tests that everyone can do with their design and code to help to ensure that your site is accessible.
Keyboard: does the site make sense when you tab through with a keyboard? Does the view jump around taking inputs out of the context of their labels when you navigate using the tab key, particularly with a zoomed or restricted viewport?
Technical Note: using the tabindex property on your link and form input elements helps you control over how a keyboard user navigates through a page.
Screen: Contain the viewport, zoom into a small part of the page. Can you still effectively use the site?
Voice: Most modern computers come with a built-in screen reader. All Macs come with VoiceOver out of the box. They’re not quite as good as the likes of JAWS but if your site works with VoiceOver, it’s a very good indicator for the more expensive solutions.
I hope you found my write-up helpful. I'm aware it's perhaps one for the developers amongst us. I found the talk inspiring and wanted to share. If you are interested to learn more, than there's some tools and further reading below.
Tools and further reading
There’s a growing number of tools now available to help improve accessibility through both design and code, including Microsoft’s Inclusive Design Toolkit.
This set of posters will help you remember the basics.
There’s also a huge amount of information around to help you make Accessibility a core part of your process. A good place to start is the Simply Accessible blog.