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.
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!
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
-
WAI-ARIA
Specifies accessibility attributes that- a browser developer should recognize from code it interprets
- a web page developer should put in their code
-
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
The keys is to make this as close to human language as possible, for a comfortable user experience.
For Web Page/App Developers:
-
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)
-
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
-
Has attributes you can use like:
- doc-chapter
- doc-credits
- doc-glossary
For Web Browser Developers:
-
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. -
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. -
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
-
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
Post a Comment