Accessible Javascript with and without WAI ARIA


Published on

Presentation held at GeekUp Leeds April 15th, 2009

Published in: Design, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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


    Site-orientated content, such as the title of the page and the logo.


    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.


    Child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.


    Content that is directly related to or expands on the central content of the document.


    Content that contains the links to navigate this document and/or related documents.


    This section contains a search form to search the site.

  • aria-valuemin

    Stores the lowest value a range may have.


    Stores the highest value a range may have.


    Stores the current value in a range.


    Stores readable text to help the user understand the context. For example,
    \"30 dollars\"


    Stores the
    attribute of a text label containing an appropriate prompt for this widget.

  • Accessible Javascript with and without WAI ARIA

    1. 1. Accessible Javascript with and without WAI ARIA GeekUp Leeds 15 April 2009 Dirk Ginader
    2. 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 • users of assistive technologies are able to use the page too
    3. 3. Without accessible Markup there’s no accessible Javascript
    4. 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?
    5. 5. CSS does not always make just beautiful
    6. 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!
    7. 7. Interaction is handled on the Server
    8. 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
    9. 9. Javascript is the icing on the cake
    10. 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!)
    11. 11. another layer: different CSS if Javascript is available
    12. 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
    13. 13. Screenreaders don’t understand Javascript anyway...
    14. 14. • is there still someone believing that? • most Screenreaders actually handle Javascript very well! • they just don’t know all the time
    15. 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
    16. 16. Accessibility != Screenreader
    17. 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?
    18. 18. • 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?
    19. 19. And another Layer: WAI-ARIA
    20. 20. • 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
    21. 21. Roles
    22. 22. • alert • banner • button • menuitem • slider
    23. 23. Document Landmark Roles
    24. 24. • application • banner • complementary • contentinfo • main • navigation • search
    25. 25. States and Properties
    26. 26. • aria-valuemin • aria-valuemax • aria-valuenow • aria-valuetext • aria-labelledby
    27. 27. Live Regions informing about changes
    28. 28. • off • polite • assertive • (rude)
    29. 29. You can use it today
    30. 30. • it does no validate • you can simply add the properties using Javascript as it depends on it anyway
    31. 31. • everybody can add Landmark roles now • aria-required=”true” makes a dream come true
    32. 32. Don’t rely on it
    33. 33. • 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...
    34. 34. more • • • •
    35. 35.