The document is a presentation by Andrew Ronksley from the Royal National Institute of Blind People on web accessibility. It discusses assistive technologies, improving accessibility through proper HTML semantics and structure, use of external CSS, testing with keyboards and real users. It also covers JavaScript and how WAI-ARIA helps make dynamic content accessible by providing semantic information to screen readers. ARIA is presented as a way to repair inaccessible HTML5 and add support for widgets not natively covered.

1. Web
Accessibility –
We're All In
This Together!
ThoughtWorks Team
Meeting – January 2013
London, UK
Andrew Ronksley
Digital Accessibility Development Officer
Royal National Institute of Blind People

2. 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?

3. 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.

4. Simple steps to improving web accessibility...

5. 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.

6. 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.

7. Give your mouse the day off...
...test with the keyboard only.

8. 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.

9. Test it with real end users...
...make sure it's not a car crash!

10. 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.

11. 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.

12. 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!

13. 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!

14. Thanks for listening! Any questions?

15. 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

16. 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/