Accessible Javascript using Frameworks - Barcamp London 5
1. Accessible Javascript
using Frameworks
Dirk Ginader
http://ginader.de
Friday, March 6, 2009
2. 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
Friday, March 6, 2009
3. Without accessible
Markup there’s no
accessible Javascript
Friday, March 6, 2009
4. • 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?
Friday, March 6, 2009
5. CSS does not always
make beautiful
Friday, March 6, 2009
6. • 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!
Friday, March 6, 2009
8. • 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
Friday, March 6, 2009
10. • 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!)
Friday, March 6, 2009
11. another layer:
different CSS if
Javascript is available
Friday, March 6, 2009
12. • 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
Friday, March 6, 2009
14. • is there still someone believing that?
• most Screenreaders actually handle
Javascript very well!
• they just don’t know all the time
Friday, March 6, 2009
15. • 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
Friday, March 6, 2009
17. • 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?
Friday, March 6, 2009
18. • what happens if a page gets scaled up or
down?
• screen magnifiers only show a very small
part of the screen
• does really every understand what happens
on the page right now?
Friday, March 6, 2009
19. How do
Javascript Frameworks
help with this?
Friday, March 6, 2009
20. • reducing the pain of Javascript cross
browser issues by unifying their APIs
• the right timing counts: onDOMReady
• don’t reinvent the wheel every day: ready
made components help!
Friday, March 6, 2009
21. • the components of the big JS frameworks
are usually tested extensively against
stability, usability and accessibility
• testing against Screenreaders makes sense
with “real” Screenreader users only
Friday, March 6, 2009