I’m currently working on a rather large project at work, the BBC sport olympics website. Being one of the tech leads and a big advocate of accessibility and user experience I’ve been doing a lot of research and learning around making websites accessibility and trying to ensure that the site we deliver is accessible and usable by people with a wide range of abilities, devices and assistive technologies.
In this first article I want to chat about about accessibility and interoperability and share a list of browser tests that can be used to identify potential problems. I’m planning a further articles to explain the list in more depth – and how to use it as an approach to building an accessible web page or component, as well as using it to test a page webpage that someone else has built.
The challenge of web development
As web developers we want to try and make sure that our web page and application works for as many people as possible – but are faced with the challenge of not knowing who is going to access our webpages or how. It’s wrong to assume that everyone is a sighted user using a mouse, the latest browser, a large monitor and a broadband connection.
Here are some of the things that are variable for each user:
- Desktop computer
- Mobile phone
- old browsers
- modern browsers
- obscure browser (lynx, PS3)
- brand new / future browser
- Pen graphics tablet
- touch screen
- voice recognition
- remote control
- head, mouth and eye operated controllers
- Screen (and at what resolution?)
- Touch – refreshable Braille device
Connection (bandwidth and cost)
- narrow band
- font size
- images on/off
- user stylesheet
- Full hearing
- Partial hearing
- Able bodied
- Traumatic Injuries
- Loss or damage of limb(s)
- Spinal cord injury
- Diseases and Congenital Conditions
- Cerebral palsy
- Muscular dystrophy
- Multiple sclerosis
- Spina bifida
- ALS (Lou Gehrig’s Disease)
- Parkinson’s disease
- Essential tremor
- Deficits or difficulties
- Reading, linguistic, and verbal comprehension
- Math comprehension
- Visual comprehension
- screen reader
- screen magnification
- speech recognition software
- switch device
Furthermore, many of these are situational so can change for a user over time – e.g location, injury and ageing.
- Eyesight, motor and cognitive abilities deteriorate with age.
- A user may suffer a hand injury and be forced to use a keyboard rather than a mouse.
- A user may be forced to use an old browser at work.
What is Interoperability and Web accessibility?
Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation.
Accessibility is a general term used to describe the degree to which a product, device, service, or environment is available to as many people as possible. Accessibility can be viewed as the “ability to access” and benefit from some system or entity. Accessibility is often used to focus on people with disabilities or special needs and their right of access to entities, often through use of assistive technology.
Web accessibility refers to the inclusive practice of making websites usable by people of all abilities and disabilities.
Universal design refers to broad-spectrum ideas meant to produce buildings, products and environments that are inherently accessible to both people without disabilities and people with disabilities.
Not just a developers responsibility
As a developer there is a lot we can do to make something more or less accessible. There is, however, also a lot that is out of our control.
Some accessibility falls to the responsibility of the content producers – providing good labels, understandable text and helpful alt text for editorial images.
Some falls to the responsibility of the designers – color contrast, not relying on only color to convey information, not having auto updating content without the ability to turn it off. The order of content can also be affected by the design.
Some accessibility falls to the responsibility of the product owner – factoring in accessibility from the start of the project, allowing time for developers to learn and implement accessibility and including accessibility testing in the product timeline.
How does a developer build something that is both interoperable and accessible?
- Add your content to a page in a logical reading order. To your content add the most appropriate (semantic) elements and attributes, add good heading structure and WAI-ARIA landmark roles. Add aria-labellby and aria-describedby where helpful.
- Apply CSS to achieve the visual design.
- Test. Test. Test. See below for some suggested tests for developers. If possible also include an audit by an accessibility expert and user testing with disabled users.
Following steps 1 -4 does not ensure accessibility. It’s easy to introduce accessibility issues in each layer – which is why it’s so important to test your pages.
- In the html layer something as simple as duplicating links or not having alt text for images can reduce the accessibility of a page. As can incorrect heading structure – or badly marked up tables and forms. Don’t assume assistive technologies will understand new HTML5 elements.
- In the CSS layer common problems include accidentally hiding content from a screen reader by using display:none, or by keyboard focus not being visible.
- Support for WAI-ARIA varies in different browsers and screen readers.
- A developer following best practice AND testing a page is still unlikely to catch all accessibility issues – which is why getting accessibility user testing is so important if you can.
Another important thing to mention is that interoperability doesn’t mean spending lots of time trying to provide an identical experience in all/older browsers. It’s important that old browsers (such as IE6) can get the core content and core functionality (i.e read the text, submit forms and click links)- but not important the that visual design is identical or that enhanced functionality is available. As Nicholas Zakas explains in his recent Progressive enhancement 2.0 presentation – we should utilize the capabilities of a browser and be forward thinking, not wasting time trying to get old browsers to have an identical experience.
For a good summary on why it’s fine for a website to not look identical in all browsers see Where are my rounded corners
Why go the extra distance to achieve interoperability and accessibility?
- professional obligation: looks amateur if what we have built doesn’t work for someone. Will be seen as buggy code.
- moral obligation: the web is an enabling tool that can vastly improves the live of many disabled people – but only when web pages work with assistive technologies.
- legal obligation: The Equality Act requires us by law to make websites accessible. If someone with a disability, such as sight loss, can’t access the information on your website then it could be seen as discrimination.
Browser based tests for accessibility and interoperability
How do you identify if what you have built is both interoperable and accessible? Here’s a list of suggested tests to quickly identify accessibility issues. Thank to Henny Swan and Hans Hillen for feedback and additions. Huge thanks to Hans and Steve Faulkner at The Paciello Group for a fantastic WAI-ARIA course and support desk and to Robin Christopherson at AbilityNet for a great screen reader course
- Is all core content available?
- Is content in a logical reading order?
- Has correct semantic markup been used?
- Has a logical heading heirachy been used?
- Are there any duplicate links or links without useful labels?
- Check for a language specification on each page as well as individual parts where different languages are used
- If iframes are used check they have meaningful titles to explain their purpose
- Check wai-aria landmark roles are being used correctly
- Is all core content available?
- Check for any broken functionality – e.g do all links work (Make sure that no links have <a href=”#”>)
- Has progressive enhancement been used?
- Check for display:none – has any content been hidden?
- Load in a users stylesheet to confirm that your stylesheet is overrideable – e.g http://simplyaccessible.com/article/custom-styles-for-ios/
- Can you do everything effciently? Can you complete all actions?
- Is it obvious what has focus? (use :focus as well as :hover)?
- Have correct controls been used – e.g links, buttons and inputs?
- Does the space bar work on all elements that have role=”button”?
- Has focus and linear flow been managed properly? Make sure there aren’t any keyboard traps?
- Forms – check for success case, error case, the ‘correction’ case
- Make sure you are not killing other keyboard functionality
- Can pop-ups/dialogs be closed with the escape key? Does focus return to item then opened it?
- Is the virtual buffer updated when ajax is used to insert new content into the page – is the user notified of an update or focus set to the new content?
- Is all content and functionality accessible and usable?
- Are tables accessible?
- Are forms accessible?
- Has WAI-ARIA been used to improve accessibility/usability?
- Are users notified of new content or taken to it by setting focus to it?
- Is page still usable – checking for alt text and color contrast (e.g no white text on white a white background)
- Is text still readable?
- Does the text or content truncate or overlay?
- Are there huge empty spaces between form fields and labels?
- Are all parts of the page still usable?
- Is all core content available/usable?
Use a tablet – e.g iPad
- Does eveything work on a touch device?
- With Voiceover on are all images labeled?
- Are changes of state notified?
Use a Printer
- Is core content readable?
- Make sure width of content is not too wide for paper
- Is a minimum number of pages printed out – don’t want to infuriate users by wasting paper!
Run automated tests
- Run a colour contrast checker
- validate HTML – http://validator.w3.org/nu/ (if your page is html5 and has microdata choose: HTML5 + SVG 1.1 + MathML 2.0 + RDFa 1.1 + Microdata)
- Use a link checker
If you’ve got to the end of the post – thanks for reading! Took rather longer to write that I was expecting – but has hopefully been useful. If you have additions/amends to the browser tests please let me know and I’ll add them.
In a future post I’ll go into more details about the how’s and why’s of building a webpage that conforms to this list – and also some tools that can be used for testing them.
- Five Layers of Accessibility
- Accessibility for the Modern Web by Derek Featherstone – Fronteers 2011
- HTML5 Accessibility: Is it ready yet? By Steve Faulkner & Hans Hillen – Fronteers 2011