over 90 different roles to map existing OS concepts onto your Markup
article
Content that makes sense in its own right, such as a complete blog post, a comment on a blog, a post in a forum, and so on.
banner
Site-orientated content, such as the title of the page and the logo.
complementary
Supporting content for the main content, but meaningful in its own right when separated from the main content. For example, the weather listed on a portal.
contentinfo
Child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.
main
Content that is directly related to or expands on the central content of the document.
navigation
Content that contains the links to navigate this document and/or related documents.
search
This section contains a search form to search the site.
aria-valuemin
Stores the lowest value a range may have.
aria-valuemax
Stores the highest value a range may have.
aria-valuenow
Stores the current value in a range.
aria-valuetext
Stores readable text to help the user understand the context. For example, \"30 dollars\" .
aria-labelledby
Stores the id attribute of a text label containing an appropriate prompt for this widget.
Accessible Javascript with and without WAI ARIAPresentation Transcript
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
• 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
• 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
article
Content that makes sense in its own right, such as a complete blog post, a comment on a blog, a post in a forum, and so on.
banner
Site-orientated content, such as the title of the page and the logo.
complementary
Supporting content for the main content, but meaningful in its own right when separated from the main content. For example, the weather listed on a portal.
contentinfo
Child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.
main
Content that is directly related to or expands on the central content of the document.
navigation
Content that contains the links to navigate this document and/or related documents.
search
This section contains a search form to search the site.
aria-valuemin
Stores the lowest value a range may have.
aria-valuemax
Stores the highest value a range may have.
aria-valuenow
Stores the current value in a range.
aria-valuetext
Stores readable text to help the user understand the context. For example,
\"30 dollars\"
.
aria-labelledby
Stores the
id
attribute of a text label containing an appropriate prompt for this widget.