Jolting down webAccessibility
I have been going through a lot of articles and broken accessibility for me or someone like me who is fairly new to web and web’s accessibility
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect,” said Tim Berners-Lee, W3C Director and inventor of the World Wide Web
We often shorten the word “accessibility” to “a11y” because there are 11 letters between the “A” and “Y” in the word “Accessibility”. Sometimes you’ll see this pattern used in other contexts like i18n for “internationalisation” and l10n for “localisation”.
without going through definitions and long explanations on what, when, where and why it is used, which i believe already read before coming to this article.
Web Content Accessibility Guidelines
WCAG is organised around four principles often called by the acronym POUR:
Perceivable : Content should be perceivable by all types of users
Operable: Interaction with UI components should not restricted with one type of device
Understandable: Understand the interface and is it consistent enough to avoid confusion
Robust: Content be consumed by a wide variety of user agents (like browsers and assistive technology)
Practical aspects of accessibility
- FOCUS Focus determines where keyboard events go in the page, it ensures that UI is assessable for all users
Web AIM WCAG checklist 2.1.1 States that
All the functionalities should be available using the keyboard, unless the functionality cannot be achieved by a keyboard like free hand drawing.
Move focus around the page using your keyboard:
- TAB will move focus forward
- SHIFT — TAB will move focus backwards
- Arrow keys can be used to navigate inside of a component
Tab order depends on DOM order
<button style=“float:right;”>1</button>
<button>2</button>
For screen reader it would be 1 and 2 while in display it still is 2,1
Web AIM WCAG checklist 1.3.2
States that
The reading and navigation order is logical and intuitive, Tab index can be applied to any HTML element and takes numeric values
<div tabindex=“0”> Hocus focus </div>
tabindex=-1
Will not be in tab order but can be programatically focussed via JS by calling element focus() method
Document.querySelector(‘#model’).focus()
2. Semantics ensuring that a website supports assistive technology uses is going to come down to programatically expressed semantics
Web AIM WCAG checklist 4.1.2
Name, Role, Value: For all user interface components, the name and the role can be programmatically determined; states, properties, and values that can be set by the user can be programatically set.
A screen reader actually largely creates the user interface for user based on programatically expressed semantics Instead of visual ui, it provides auditory interface.It provides Role Name state and value
Assertive technology takes the DOM tree and modifies to turn it into a form which is useful for assistive technology
<button> click </button>
For any assistive tech “Search, button”
Guideline 1.1
Text Alternatives: Provide text alternatives for any non text content
Html provides
Vsible labels
-Like Radio button
Text alternatives
-For Images
Web AIM WCAG checklist 1.1.1
1.1.1 states,
- All Images form image buttons and image map hot spots have appropriate, equivalent alternative text
- Images that do not convey content are decorative or contain content that is already conveyed in text given null alt text (alt=“”) or implemented as CSS backgrounds. All linked images have descriptive alternative text
Form buttons have destructive value
<button> click </button>
For any assistive tech “Search, button”
Form inputs have associated text labels
<input type=“checked” name=“terms”> Agree to terms ?
We either achieve this by wrapping around label element
<label> <input type=“checked” name=“terms”> Agree to terms ?</label>
or we can use for attribute
<input type=“checked” name=“terms” id=“terms”><label for=“terms” > Agree to terms ? </label>
For any assistive tech “Agree to terms ,Checked,checkbox”
significant images needs to be given alt text else alt text should be empty for screen reader to skip else screen reader would try to read the file name
ARIA Express semantics when native HTML won’t cut in
Web Accessibility Initiative
Accessible Rich Internet Applications
WAI-ARIA — Is good for bridging areas where there are accessibility issues can’t be managed with active HTML
<div tabindex+”0” class=“checkbox“ role=“checkbox” aria-checked=”false”>
Terms
<div>
For any assistive tech “checkbox Name: terms State: unchecked”
Aria roles : https://www.w3.org/TR/wai-aria-1.1/#roles
ARIA in HTML spec, including guidance on what ARIA roles may and may not be used with which HTML elements
Aria Label Aria is the only way to add labels for accessible label or description texts
<button aria-label = “close”>Close<button>
aria-labelledby refer to as a relationship attribute, which creates a semantic relationship between elements of the page
<div role =“radio” aria-labelledby=“coffee”><div>
<span id=“coffee”>Coffee</span>
Another important technique for use of assistive technology is that only the relevant parts of the page are exposed to assistive technology
Anything which has
style=“visibility:hidden”;
style=“display:none”
hidden attribute of HTML5
Will also be hidden for assistive tech.
aria-live :- updates that should be commnunicated in timely manner rather than when explored the page
<div class=“alert” aria-live”assertive”> Failed </div>
Aria live has 3 allowable values
off — default value — updates the region will not be presented to user unless the assistive tech is currently focusd on it
Polite- assistive technology should announce updates at the next graceful opportunity such as the end of speaking sentence
Assertive- the information has the higher priority and assistive technologies should notify the user immediately.
you can find more on ARIA @ https://www.w3.org/TR/html-aria/
hope this helps :)
WITH GREAT DESIGN COMES, GREAT RESPONSIBILITY