web accessibility - we're all in this together!

Web Accessibility – We're All In This Together!

ThoughtWorks Team Meeting – January 2013London, UK

Andrew RonksleyDigital Accessibility Development OfficerRoyal National Institute of Blind People

What's an “assistive technology”?

And does anyone in the room use any?

Sure, any specialist software / hardware designed for disabled people counts, but does anything else count as well?

Despite it being smashed beyond belief, my mobile to me (and to everyone) is an “assistive technology”.

Without it, I can't call my mum because human hearing doesn't work over a range of 200 or so miles.

I need the technology to “extend my capabilities as a human”.

To that end, I see almost all technologies as “assistive technologies”.

So I normally just refer to “technology” these days.

Simple steps to improving web accessibility...

Don't use fixed font sizes and colours...

Designers want it “my way”. Let users take the “highway” if they want.

Keep all styles in external CSS (avoid inline styles).

Avoid “px” values for font-size and line-heights (Internet Explorer won't resize them).

A style switcher is nice to have but not an essential feature.

Consistency is a virtue...

Aim for consistency across your interface both in terms of locations and shape / colours of items.

Give your design room to breathe but avoid large amounts of white space between related controls. Pure white space is difficult to traverse for screen magnification users.

Consistency can really help disabled users once they become familiar with your site or application.

Give your mouse the day off...

...test with the keyboard only.

Be kind. Be semantic.Write great, descriptive HTML. Use <title>, <h1-h6>, <ul><li>, <label for=””>.

Alt attributes – describe the purpose of the image. If it doesn't have a purpose, use alt=”” or a css background image instead.

Link text – every time you use “Click here” something bad happens to my niece's kitten.

If you have tabular data use table markup! <th>, <td> and scope.

CSS – be careful with display: none. Screen readers parse this and won't always read content out (which may be what you want). Use absolute positioning off-screen if you want the content available though.

Test it with real end users...

...make sure it's not a car crash!

JavaScript...doer of accessibility evil!

Sensationalist and not true! Like any other web technology, it comes down to how you use it.

To my knowledge, screen readers don't parse JavaScript directly.

They rely on information given to them from the browser via the platform accessibility API for the operating system in use.

Where JavaScript causes a problem is when it manipulates the DOM without a page reload and is used to create custom “widgets” that don't natively exist in HTML.

How does WAI-ARIA help?

Despite being intrinsically linked with JavaScript, WAI-ARIA is actually a “semantic plaster / bandaid” for HTML (not bacon flavoured unfortunately!)

ARIA markup is just additional attributes that you can add to your HTML document and manipulate through your scripts.

It's super easy and already comes “baked-in” to a lot of popular JavaScript UI libraries.

How does WAI-ARIA help?

ARIA allows you to specify what the role of something is, e.g. if you have a bunch of <div> elements faking a menu, use role=”menu” and role=”menuitem” to “repair” it.

Using ARIA you can also mark an element of a page as a “live region” if it gets updated dynamically through DOM manipulation or the result of an AJAX call.

Guess what? Most of this stuff needs both browser and screen reader support!

What's the deal with WAI-ARIA and HTML5?

HTML5 is incorporating elements of ARIA. For example, there's a native <menu> element which can be used rather than <div> and role=”menu” and <input type=”range”> can be used instead of role=”slider”.

ARIA has support for more widgets than HTML5 native elements though. For example, tree views, modal dialogs and live regions. It's not dead as a specification yet.

The HTML5 specification has a number of mapping tables that outline the relationship between the two specifications. They're definitely worth checking out.

Finally, I don't need to tell you that HTML5 depends on browser support as well!

Thanks for listening! Any questions?

www.rnib.org.uk/wac

www.rnib.org.uk/professionals/softwareandtechnology

www.paciellogroup.com/blog/ (for the latest WAI-ARIA / HTML5 information)

www.linkedin.com/in/andrewronksley

Thanks to the following awesome Flickr users for letting me use their images:

http://www.flickr.com/photos/altogetherfool/3543142490/http://www.flickr.com/photos/--sam--/4486809849/http://www.flickr.com/photos/guydonges/2649517251/http://www.flickr.com/photos/kenwilcox/3883031017/http://www.flickr.com/photos/functoruser/2437807188/http://www.flickr.com/photos/30998987@N03/5408763997/http://www.flickr.com/photos/eamoncurry/3335785800/http://www.flickr.com/photos/methodshop/6397366607/http://www.flickr.com/photos/arnehendriks/3360303148/http://www.flickr.com/photos/22290288@N03/5865026309/http://www.flickr.com/photos/11513812@N02/1394620294/http://www.flickr.com/photos/junit16/6036682072/http://www.flickr.com/photos/wwworks/4759535950/