My 2019 WebAIM Training Notes

WebAim Training.md

[!info] Notes originally taken on May 7, 2019.

WebAIM Training Notes 

WCAG Information 

[!example]- Links

• Official WCAG Spec
• WebAIM Checklist
• HTML 5 Accessibility
• Contrast Checker
• WAVE (Web Accessibility Evaluation) Tool

Classifications 

• WCAG A (Low; an OK start) 
• WCAG AA (Medium)
• WCAG AAA (High; not always required) 

WCAG 2.1

[!info] Between the time these notes were written and 2023, WCAG 2.2 became a thing.

• Includes New Guidelines for Mobile.
• Don't rely on Input Modalities (e.g. click and drag).
• Don't rely on device motion.
• Use up action events instead of down action events.
• Large clickable targets (>= 44x44 px).
• Make sure clickable items look clickable.
• Be careful with inactive/disabled controls that only look disabled because not all users understand what that might mean.

Label (WCAG)

• Is presented visually. 

Name (WCAG)

• Is presented to accessible technology.
• Typically contains or is the label.
• Can be hidden visually.

Colors and Contrast

• Doesn't take into account hues, that has to be done by common sense.
• Higher Contrast between background and other colors is the goal.
• Use common sense when considering color contrast. When considering color contrast, consider the gray scale color contrast.
• Be careful with outlined text or other visual effects and how that would affect the contrast.
• Text over images should be evaluated; e.g. Color contrast of image, busyness, gradients, etc.
• Consider how the content will be viewed (colors on a projector would be different than a screen).
• Don't convey information exclusively through color (e.g. required fields are marked in red).
• Low contrast can convey unavailable options (e.g. grayed out options in a form that can't be modified).

HTML Rules and Elements 

• Make options that should only be read by screen readers hidden with CSS.
• Only use HTML elements for their intended purpose; Make sure it's well formatted.
• Make everything appropriately labelled so that screen readers can correctly navigate the page.
• Be consistent for the entire site.
• a:hover should be a:hover, a:focus.
• Also use focus-within.

Headings 

• Headings are vitally important for screen readers.
• Headings should describe a section of content.
• Usually only <h1> per page; Should describe the page.
• Do not skip heading levels; Go from h1 to h2 to h3. Treat as a collapsible document.

Title

• Should be succinct and descriptive.
• Put the most useful information first .
• Should usually match or be similar to the <h1>.

Links

Design 

• If not underlined WCAG requires a 3:1 color contrast and there should be a non-color cue on both mouse hover and keyboard focus.
• Needs to have good contrast from both the background and the main body text.
• Typically underlined to clearly be a link.

Text 

• Have appropriate non-ambiguous descriptive links (e.g. 12 "Learn More" links does play nicely with screen readers; same for "Click Here").
• Headings can be links, mobile friendly.

Alternative Text

• Read by screen readers.
• Used if images don't load.
• Used by (not for) search engines.
• Rarely a description, typically for content and function.
• Text in images generally should be in alt text.
• Via the alt attribute or in the context of the image (in which case alt="").
• If an image is the only thing inside a link it must have alternative text.
• Decorative images should have null alt text (alt="").

Should...

• Be accurate and equivalent
• Be succinct
• Not redundant
• Not use "image of..." or "graphic of..."

Complex Images

• Provide alternative context or direct the user to a page with a full description.
• Infographic should link to a separate page that fully describes the infographic.

Figure and Figcaption

• Content that can be removed without impacting the primary content
• Figcaption summarizes the figure; doesn't replace alt text.

Hide Content 

Hide from everyone (including screen readers): 

• display: none
• visibility: hidden 
• HTML hidden attribute

Hide visually:

• class=".sr-only"  (bootstrap)
• CSS clip and or clip-path (new to CSS, may not be universally supported at time of writing).

Hidden "Skip" links 

• Should be one of the first things on the page.
• a#skip and a#skip:focus; skip hides it like sr-only (far off the page and reduced to 1x1 pixels.
• "Skip" links; e.g. <a href="#content">Skip to main content</a> 
  • WCAG doesn't require this, rather a mechanism to bypass content.

Tables

• Only use tables only if it makes sense (the content would be at home in a spreadsheet).
• Don't use them to structure pages when you could use something else like columns.
• Don't reinvent the wheel, use what's available.

Layout Tables

• Simple content could use tables (don't lol, use grid or flex).
• role="presentation"

Data Tables

• Need to provide specific associations, not just visual associations.

<table> 
	<caption>Table Name</caption> 
	<tr> 
		<th>column header</th> 
		...
	</tr> 
	<tr> 
		<td>Cell value<td> 
		...
	</tr>
</table> 

• Column headers that span multiple cells should be turned into a table caption.
  • Split tables that have multiple sets of this.
• Don't use data tables and data table elements if it's not a data table.

Title Attribute

• Advisory information only.
• Not accessible to keyboard and touch screen users.

Should be read for…

• Form elements missing labels
• Frames and iframes
• <abbr>/<acronym>… usually.

Odds and Ends

Lists

• <ol> for ordered, hierarchical lists
• <ul> for unordered, bulleted list
• <dl> for definition/description list (name/value pairs, FAQ's)

Frame Title 

• On <frame>, title is required
• On <iframe>, title is not required

Fonts & Texts

• Absolute (px, pt, etc.) or relative sizes (%, em etc.).
• Choose good, legible fonts.
• Be careful with all caps; avoid if possible.
  • Screen readers are more likely to read uppercase letter by letter, especially if it's a known acronym.
  • If needed, use CSS text-transform: uppercase;
• Consider special characters and verbosity.
  • Some characters (punctuation) are skipped by screen readers.
    • $.99 and $99, will likely be read the same.
  • Use minus symbol for negative numbers, not the dash
• Avoid Full Justification.
• Language of Page <html lang="en"> (WCAG A).
  • Language of Parts <div lang="fr">

Text Spacing (Level AA)

• Paragraphs: 2 x font size 
• Lines: 1.5 x font size 
• Etc. (there are more) 

Forms

• Use the correct input type. 
• HTML5 and browsers support many input types <input type="date | time | search | etc…">
  • date
  • time
  • search
  • url
  • number
  • range
  • color
  • email
  • tel
• Be careful with autofocus

Form Labels 

<label for="fname">First Name:</label>
<input type="text" id="fname" … 

• <input> tags can also be wrapped in their label tag (implicit form label).
• This method also makes the text clickable. 
• Already filled inputs could become the labels for other form elements. 
• Order of importance (top overrides lower): 
  • aria-label
  • aria-labelledby
  • Form label
  • Title attribute
  • Alternative text
  • Link text
  • Button text

ARIA with Form Labels 

• aria-labelledby on the input that points to the label.
  • Don't use if already using the HTML equivalent.
  • Breaks rule 1 of ARIA, don't replace simple HTML equivalent.
  • Works well when one label is connected to multiple form elements.
  • Works well when one form element is connected to multiple labels.
• ARIA Labels override default accessible names.
• aria-describedby is what describes the small italicized characters beneath a text input (e.g. Must be 8-15 characters).
• ARIA attributes are read first with by screen readers, so be careful with things like error messages.
• Elements must be "label-able".
• aria-required="true" will read out to the screen reader that the form element is required, but it does not make the element required. Use the required attribute as well.
• aria-invalid="true" indicates to the screen reader that the form element is invalid. Has browser bugs and isn't very recommended.

Grouping Inputs

<fieldset> 
<legend>This is a title for a group</legend> 
<input id="overnight" type="radio"…> 
<label … 

Hidden Labels 

• sr-only on a label that normally wouldn't visually display one will help screen readers (recommended).
• Title attributes on the input could also work.

Autocomplete Attribute 

• autocomplete="given-name" 

Placeholder Text 

• Don't include crucial information in the placeholder text.
• Use with caution.
  • Have low contrast.
  • Can't see the placeholder when the text is filled.

Form Validation and Error Recovery 

Avoid…

• Collecting unnecessary info.
• Forcing users to provide formatting unless necessary.

Identify

• Let the users know there is an error.
• Direct users to errors.
• Describe the error.

Suggest… 

• How to fix it.

Prevent

• Important changes are reversible/checked/confirmed.

Form Validation Types

Alert, then focus to the invalid element. 

• Good for simple forms.

Errors at the top

• Group errors at the top.
• Good for longer forms that may have several errors.
• Can make errors links to link to the invalid input.

Inline Errors

• Has a popup on the element itself describing the error (or something inline or below the element).

CSS Generated Content 

• Icons that are added automatically from CSS rules (PDF icon after a PDF link).
• Have an "sr-only" span that describes the icon (e.g. PDF) so that screen readers can read the icon.

ARIA (Accessible Rich Internet Applications)

• Rule Number One: Only use ARIA if there aren't existing HTML regions. e.g. Use these before ARIA: 
  • <header>
  • <nav>
  • <main>
  • <region>
  • <aside>
  • <footer>
• Used to convey additional and more technical description for an element.
• Typically used on <div>.
• Use appropriate ARIA roles.
• "Region" and "Landmark" are identical to screen readers.
• Screen readers navigate via <region>.

Roles, States, and Values 

Cognitive/Learning Disabilites

• Largest disability group
• User needs vary greatly; focus on generic recommendations
  • Be careful with movement and other distractions
  • Use good organization
  • Focus on important content
  • Simplify

Avoid… 

• Small text
• Avoid long line lengths
  • Optimal is 45-60 characters

Misc.

• Make the page navigable via the tab key (focusable elements).
• Don't make alt text excessively long.
• Ctrl + Alt + Arrow Keys lets one navigate a table (for some screen readers)
• Avoid outline: none; and outline: 0;
• Plan for user experience, not just from a professional perspective. 
• Don't focus exclusively on most visited; Also focus on important elements (e.g. submit buttons for forms need to be accessible).
• Focus on accessibility from the start that is equivalent for all users.

WCAG Pause, Stop, Hide (Level A) 

• Don't interrupt user experience.
  • Pop-ups for session expiration.
• Any moving, blinking, or scrolling information that starts automatically and distracts from the main content there needs to be a mechanism to pause, stop, or hide it.

Photosensitive Epilepsy 

• Be careful with flashing/strobing content.
• Three times per second or more is too much.
• Size, brightness, and red threshold.
• "Annoying rule": if it's very annoying it might cause seizures.

Motor Disabilities 

Consider... 

• Repetition and fatigue
• Lack of fine motor control
• Control over time or moving elements

Standard Keystrokes 

• Allow keystrokes for navigating the page and forms.

For example... 

• Link: Enter
• Button: Enter or Spacebar
• Radio Buttons: ←/→ vs ↑ / ↓
• Escape Key

ARIA Workshop

Overview

Rules of ARIA 

• Rule #1: Don't use ARIA, unless you have to.
• Rule #2: Don't change native semantics, unless you have to.
• Rule #3: All interactive ARIA controls must be usable with the keyboard.
• Rule #4: Don't use roles or aria-hidden on things that are visible, focusable elements.
• Rule #5: All interactive elements must have an accessible name.

Important Information 

• ARIA expands the vocabulary of HTML to support what screen readers already understand.
• ARIA does not change functionality; it only changes the presented roles/properties to screen reader users. The web author needs to code the functionality with JavaScript or something similar.
• ARIA only makes things more accessible.

ARIA 1.1 Authoring Practices

Keyboard Navigation

• Use links/buttons appropriately; Don't reinvent the wheel.
• Ensure interactive elements are links or form controls.
  • Make non-focusable elements focusable with tab index. Avoid this if necessary.
  • tabindex="0" makes the element focusable without actually changing the tab index. It treats it as if it were a form control.
  • tabindex="-1" allows non-focusable elements to receive programmatic focus (by scripting, links, etc.).
    • Necessary for focusing dialog boxes, error messages, etc.
    • Removes element from the default tab order.

Modal Dialog

• Should be a link or button.
• Should have aria-haspopup="dialog".
• Have a tabindex of -1 and set focus to it on popup.
• Only use them to convey information; Putting form elements in there to gather information (buttons to close are fine) should not be done.
• Should be closeable with the ESC key.

Trapping Keyboard Focus 

• Typically a bad idea (except for dialogs, menus, etc.).

Foreground Content

• Manage focus and aria-modal="true"

Background Content

• Uses aria-hidden="true" until it shows up, but then it needs a tabindex of -1 to be navigable with scripts.

Focus Management

"Freak-out" Mode

• When currently focused element disappears or is significantly modified.
• Avoid it or address it with focus();

Non-modal Dialogs

• Follow the ARIA design patterns.
• When possible, use HTML native input types.
  • e.g. <input type="date">

Carousels 

• https://shouldiuseacarousel.com/

Issues

• Distracting and confusing.
• Engagement with them is very low (less than 1%).
• "Freak-out mode" when carousel changes.
• Difficult interaction model.

Solutions 

• Avoid auto-playing.
• When obvious controls are used, interaction is much higher.
• An idea is to have it stop playing on hover or interaction.
• Ensure accessible content.

ARIA Roles

• Avoid duplicating default rules.
  • e.g. <button role="button">
• Accessibility can be destroyed by adding unnecessary attributes.
• aria-label can differentiate multiple landmarks of the same type.

Generic Regions

• Give role="region" and an aria-label to create custom regions.
  • Generic regions must have a label.
  • aria-labelledby is less likely to break in the event of copy paste.

ARIA States and Properties 

• Elements can have more than one aria- attribute.
• aria-checked="false" for checkboxes.

ARIA Headings 

• aria-level="2" can technically be used, but <h2> already handles the accessibility.

ARIA "fieldset/legend"

• Give roles for groups and give an aria-label or aria-labelledby.

ARIA with SVGs 

• <img> only needs alt text.
• <svg> needs role="img", and an aria-label or aria-labelledby.

ARIA Dialogs, Expanded, etc.

• Many aria- attributes for dialogs, expanded, etc.
  • e.g. aria-expanded="false"

AIRA …

• Basically, there are AIRA codes for every HTML elements that can be used in the event the HTML elements cannot be used.

ARIA Live Regions

• Look 'em up, they can do quite a bit. Basically can force the screen reader to immediately read out some important information.

Windows Screen Reader Modes

• Reading / Virtual Cursor / Document / Forms / Application
  • Can change the mode with the role attribute.
    • e.g. role="document"
  • Be careful when setting the mode as it may restrict the user's screen reader; the intention is for the author to provide key controls in that case.