Accessible Javascript
with and without
WAI ARIA
GeekUp Leeds 15 April 2009
Dirk Ginader
http://ginader.com
http://twitter.com/ginader

What makes Javascript
“Accessible”?
• the content of the page is at least as
accessible with Javascript as without
• nothing is being withheld from users
without Javascript
• users of assistive technologies are able to
use the page too

Without accessible
Markup there’s no
accessible Javascript

• first and foremost a Website needs to
works without Javascript
• do we use the best matching HTML
Elements for each Part of the Page?
• is the Page perfectly logic, understandable
and usable without CSS?

CSS does not always
make just beautiful

• badly used CSS is able to make a page
inaccessible long before Javascript can
• display:none and visibility:hidden are not
generally evil but sadly quite often
• hidden elements will be revealed when
you :hover over them - nice! But what
happens if you don’t use a mouse?
• CSS is for design - not for interaction!

Interaction is handled
on the Server

• anything you wanna achieve using Javascript
you need to solve without first
• a reload may not be cool anymore but it’s
exactly as necessary as it was 10 years ago
• if that is taken care of we can add some
magic

Javascript is the icing
on the cake

• Javascript is another layer above HTML and
CSS
• existing interaction elements like links or
buttons get hijacked and changed to do
their job in the Browser instead on the
server
• new interaction elements, that offer
functionality only available with Javascript,
need to be created by Javascript (use
tabable elements only!)

another layer:
different CSS if
Javascript is available

• YAY! We got Javascript! Let’s dig up the
DOM completely!
• we better leave the changes to someone
that does that job better and faster than
we can: CSS
• a simple 1 liner in the head does the+= ” js”;
trick:
document.documentElement.className
• by adding .js in front of existing selectors you can
now define Javascript aware CSS

Screenreaders don’t
understand Javascript
anyway...

• is there still someone believing that?
• most Screenreaders actually handle
Javascript very well!
• they just don’t know all the time

• inform Screenreaders about what’s
happening
• a logic and understandable workflow is the
easiest thing to test without a Screenreader
• focus() the right element
• when updating the DOM it might be
necessary to force the Screenreader’s
virtual buffer to refresh by updating a
hidden Form field

Accessibility
!=
Screenreader

• is the website usable without a mouse?
• the tab key is one of the most important
navigation tools
• do elements react on :hover and :focus?

• what happens if a page gets scaled up or
down?
• screen magnifiers only show a very small
part of the screen
• does really everyone understand what
happens on the page right now?

And another Layer:
WAI-ARIA

• mapping existing and well known concepts
from the operating systems to custom
elements in the Browser
• adding meaning to meaningless Markup
• instant updates to the user

Roles

• alert
• banner
• button
• menuitem
• slider

Document Landmark
Roles

• application
• banner
• complementary
• contentinfo
• main
• navigation
• search

States and Properties

• aria-valuemin
• aria-valuemax
• aria-valuenow
• aria-valuetext
• aria-labelledby

Live Regions
informing about
changes

• off
• polite
• assertive
• (rude)

You can use it today

• it does no validate
• you can simply add the properties using
Javascript as it depends on it anyway

• everybody can add Landmark roles now
• aria-required=”true” makes a dream come
true

Don’t rely on it

• There are no stats but we know that still a
lot of Screenreader users are stuck on old
versions without ARIA support
• Progressive Enhancement all over again...

more
• http://cli.gs/wai-aria
• http://cli.gs/accessible-tabs
• http://cli.gs/accessibilitytips
• http://cli.gs/wai-aria-video

http://ginader.com
http://twitter.com/ginader