Skip to content

Latest commit

 

History

History
400 lines (281 loc) · 13.5 KB

A11Y.md

File metadata and controls

400 lines (281 loc) · 13.5 KB
Raw

Accessibility

Source: Udacity Accessibility part of the Front end nanodegree

Table Of Contents:

1. A11y Overview

  • Definition: A11y means that site content should be available to everyone and functionality is operable to everyone.
  • It affects every user of your website, having disabilities, or others with no disabilities but can not access your website due to unresponsive design, colors, etc...

a. Screen Readers

b. WCAG , Web Aim, and POUR

  • WCAG: Web Content Accessibility Guidelines. It is about making your site POUR.

  • POUR: Percievable, Operable, Understandable, and Robust.

  • Web Aim Checklist: a checklist for ensuring that the website meets WCAG guidelines.

2. FOCUS

  • Web Aim
  • Implicity focusable elements (automatic tab order + built-in keyboard event handling) ex.:
    • input elements.
    • buttons.
  • No need to focus something if the user can NOT interact with it, or provide some sort of input from the user.
  • Focus Management- tab order is the same as DOM order even if the visual order ( by CSS ) is changed.
  • Changing the order visually can cause confusion to users depend on keyboard navigation. Web Aim.

a. tabindex attribute

  • tabindex = "-1"

[.] Not in tab order.

[.] can be programmatically focused by focus()

[.] For Off screen content (appears in response to user event) like modals.

<dialog id="modal" tabindex="-1"></dialog>
  • tabindex = "0"

[.] Insert natively Unfocusable element in tab order.

[.] can also be programmatically focused by focus()

[.] And then keyboard events get directed to it.

<div id="dropdown" tabindex="0"></div>
  • tabindex > 0

[.] In front of tab order.

[.] If multiple elements the lowest value is the first in tab order.

[.] ANTI - PATTERN

[.] Confuse screen readers and also keyboard users.

[.] Instead change elements DOM order.

👽 JS

To get tabindex value of an element: element.tabIndex;

Don't add focus to any content user will Not interact with.

❗ Exception:

This video shows an exception to this rule: https://www.youtube.com/watch?time_continue=155&v=ifW_oy9hajU

b. Skip links

  • Allows screen reader users and keyboard, or switch devices users to directly navigate towards main content of the page bypassing navigation items and other things before main content.
  • Visually hidden until it comes into focus.
<!--html code-->
<a href="#main-content" class="skip-link">Skip to main content</a>
<nav>
.
.
.
</nav>
<main id="main-content" tabindex="-1">
.
.
.
</main>

/*CSS code*/
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: red;
  color: white;
  padding: 8px;
  z-index: 100;
  }
.skip-link:focus {
  top: 0;
  }

👽 Alternate way to skip to main content.

c. Managing Focus at the component level

  • Like in case of drop down menu, tree view component. The keyboard interaction after getting focused is what we are talking about.
  • WAI-Aria guidelines provide guidance in selcting which keyboard interaction is appropriate for such action.

d. Roving Focus

  • To implement focus inside of a component.
  • For example: Radio group:

    • first radio button: 1. tabindex="0" / 2. checked / 3. focus()

    • when moving to the next element => first element: 1. tabindex="-1" / 2. remove checked / 3. unfocus :: next element: 1. tabindex="0" / 2. checked / 3. focus()

    • If it is the last element tab move us to the first element.

    • If it is the first element shift + tab move us to the last element.

    • Example

    • Video

e. Off-screen Content

  • Like drawer panel.
  • This can lead focus to visually disappear.
  • You can track the focus (active element) by document.activeElement;
  • Overcome it by setting display: none; or visibility: hidden;

f. Keyboard Trap

  • WebAim
  • It is desirable in modals when you want to trap keyboard focus inside the modal until you close it => return focus to the last focused element before modal open.
  • Example

3. Semantics Basics

a. Affordances

  • Definition: the qualities or properties of an object that define its possible uses or make clear how it can or should be used.
  • WebAim
  • Screen reader can provide info for elements' Name(label) Role State Value.
  • Browser takes DOM tree (natively semantic elements or othered with ARIA) ==modify it to==> Accessibility tree( containing all information for screen reader Name Role State Value).

b. Labeling, Naming, and Alternative text

  • WebAim
  • Element could have a visual label (name) like for radio button or text alternative like in case of images.
  • There are 2 ways of labeling form inputs.
<label>
  <input type="radio">
  Check me
</label>

<input type="radio" id="radio-button">
<label for="radio-button">Check me</label>
  • Using these labeling allow user to toggle the input element by also clicking the label.
  • alt text: 1. An alternative to the image if not loaded. 2. describe what the image about for screen reader. 3. For logos you can assign the company name for alt attribute. 4. For search icon you can leave alt with no value. This will skip it from accessibility tree. 5. Any image that is meant for decoration should have an empty alt.

4. Navigating Content

  • Screen Reader can make you navigate through headings, links, form controls, and landmarks.
  • It is important to use meaningful headings and links names.
  • Also use a good heading structure from h1 to h6 (for long complex content).
  • descriptive link text example: instead of using "learn more" links text use :learn more about bla bla".
  • link Anti-patterns video
  • Landmarks: you can navigate by landmarks <header> <nav> <main> <section> <article> <aside> <footer>

5. ARIA

  • WAI-ARIA: Web Accessibility Initiative - Accessible Rich Internet Application.

  • ARIA attributes need to have explicit values (can't be empty values).

  • What ARIA can do and what can not do:

    • Can:

    ✅ modify Accessibility tree.

    • Can Not:

    ❌ modify element behaviour.

    ❌ modify element appearance.

    ❌ add focus.

    ❌ add event handling.

  • ARIA give a semantic meaning to non semantic elements.

  • ARIA can also give a new semantic meaning to a native semantic element.

    • Example:
    <button role="switch" aria-checked="true" class="toggle">
  Enable
</button>

  • ARIA can express UI patterns which doesn't exist in HTML.

    • Example: tree widget

  • ARIA can add labels which is only accessible to assestive technology.

  • ARIA can provide semantic Relationship.

  • ARIA can provide live updates (aria-live).

  • the video explains that.

a. Role

  • Definition: Short hand for a particular UI pattern.

  • make sure that the role attribute is in the same element as tabindex attribute.

<div tabindex="0" role="checkbox" aria-checked="true" class="checkbox" checked>check me</div>

b. ARIA labelling

  • aria-label attribute

    • Can be used for element that has only a visual appearance.
    • override any other labelling such as <label>, or text content (like that for a button) except aria-labelledby attribute.
    • have the label clicking behaviour like <label>

  • aria-labelledby attribute

    • Overcome all other labelling methods.
    • refers to another element (which label it) by using a value corresponds to the id of the labelling element.
    • can take more than one element id (multiple labels) .
    • can refer to elements that are hidden for assestive technologies ( hidden for example).
    • Don't have the label clicking behaviour like <label> and aria-label.

c. Landmarks and ARIA roles

  • Landmarks may not have support in browsers' old versions. So we need to use role attribute with them. -Examples: 
    <header role="banner">
<nav role="navigation">
<main role="main">
<aside role="complementary">
<footer role="contentinfo">
<dialog role="dialog">

d. ARIA realtionships

  • ARIA relationship attributes

    • They take a reference to one or more elements on the page to make a link between them.
    • The difference is: 1. What link means. 2. How represented to users.

  • Attributes:

    • aria-labelledby
    • aria-describedby
    • aria-owns
    • aria-activedescendant
    • aria-posinset
    • aria-setsize

  • Video explains it.

  • Collection of relationship attr

e. Visible and Hidden content

  • For the seek of fine tuning the experience of users using assistive tech.

  • To ensure that certain parts of the DOM is either:

    • hidden to assistive tech. Or
    • Only visible to assistive tech.

  • Hidden:

    <button style="visibility: hidden;">
<div style="display: none;">
<span hidden>
    1. aria-hidden="true"

  • Only visible to assistive tech:

    1. element positioned absolute far off the screen. position: absolute; left: -1000;
    2. aria-label
    3. aria-labelledby or aria-describedby reference a hidden element.

f. ARIA live

  • for in time alerts to user.
  • aria-live="polite" : important but not urgent alert.
  • aria-live="assertive" : important and urgent alert.

g. ARIA relevant

  • attributes work with aria-live.

  • They are:

    • aria-atomic : when true assistive tech will present the entire region as a whole.

    • aria-relevant :indicates which type of changes should be presented to the user.

      aria-relevant="additions" ==> means any element added to live region is presented.

      aria-relevant="text" ==> means that any text content added to any descendant element is presented.

      aria-relevant="removals" ==> means that removal of any text or element within the live region is presented.

      aria-relevant="all" ==> means that additions or removals of text is presented.

      aria-relevant="additions text" (default).

  • aria-busy

6. Style

a. Focus style