Which WAI-ARIA Docs Do I Need to Read for my Profession?

There are many WAI-ARIA docs, but you don't need to read all of them.
Which one you read depends on your job, are you a Web Page/App Developer? An E-books or E-documents author? A Web Browser Developer?

This post will outline which docs you should read according to your job, and gives a sample of each doc's contents.

For all Web Professionals

  1. WAI-ARIA

    Specifies accessibility attributes that
    • a browser developer should recognize from code it interprets
    • a web page developer should put in their code


  2. Accessible Name and Description

    Describes how the screen reader determines what to say, and how to manipulate it so that it's easy to listen to.

    For example:


    It describes how
    • aria-labelledby
    • aria-describedby
    • aria-label
    • HTML5 label ta
    are used together to form a jumble of words for the screen reader.

    The keys is to make this as close to human language as possible, for a comfortable user experience.


For Web Page/App Developers:

  1. Graphics WAI-ARIA

    How to add roles so that a screen reader can understand graphics and images.

    For example:


    role="presentation" tells the screen reader that the element it's on is just used for visuals.
    The screen reader then won't put it in it's element tree and ignores it.

    Code example:


    The following code was written by Matthew Marangoni, find his Github here.


    How it Renders:




    Notice that it doesn't render any differently, as with all ARIA attributes. The div just isn't recognized by the screen reader anymore, because the programmer has indicated that it's not required for understanding the content or logical flow of the page. (It's just for presentation)

  2. WAI-ARIA Authoring Practices

    Extends WAI-ARIA written for All Web Professionals above. Authoring Practices focuses on how Web Page/App Developers should implement their code.


For Authors of E-books or E-documents:

Digital Publishing WAI-ARIA

  1. Has attributes you can use like:
    • doc-chapter
    • doc-credits
    • doc-glossary
    to structure the webpage similar to a book, so that accessible readers can access each section easily.


For Web Browser Developers:

  1. Core Accessibility API Mappings

    Specifies how each attribute should affect the browser, and how the browser should communicate with screen readers and other accessibility devices.


  2. Digital Publishing Accessibility API Mappings

    Extends Core Accessibility API Mappings above to include instructions for how to communicate code written by authors of E-documents to accessibility devices.


  3. HTML Accessibility API Mappings

    Extends Core Accessibility API Mappings above to include how to communicate code written in HTML by the webpage developer to accessibility devices

    For example:


    Browser must respond to:
    • Keyboard focus
    • Native HTML feature
    • WAI-ARIA role, state and property attributes


  4. SVG Accessibility API Mappings

    Extends Core Accessibility API Mappings above to include how to communicate code written using SVGs (a type of image) to accessibility devices

    For example:


    Browser must define how:
    • Charts
    • Graphs
    • Drawings

    act when they:
    • Have keyboard focus
    • Are implemented using native SVG features
    • Have WAI-ARIA role, state and property attributes


    Difference between SVG and other image extensions


    However much you zoom into an svg, the image will stay crisp


Now that you know what you need to read for your profession, it lowers the accessibility learning curve!
So go out and make your webpage accessible!

Comments

Popular Posts