Think "POUR"
The four main guiding principles of accessibility are:
P erceivable - provide content alternatives (images, audio, video)
O perable (without a mouse)
U nderstandable - clear and simple (writing and functionality)
R obust - works across many devices
Something everyone should know...
The four main guiding principles of accessibility are ... [and read list]
Development Considerations:
Aria
Valid HTML
Semantic HTML
Focus Management (aka - Keyboard Accessibility)
Canvas
SVG
Forms
1. ARIA
ARIA: provides a set of attributes that you can add to HTML elements.
ARIA - Accessible Rich Internet Applications -
This standard allows developers to set roles, states and properties on html elements
defines methods to make Web content and Web applications more accessible to people using assistive technology
First rule of ARIA use
First rule of ARIA use: Don't use it!
If you can use a native HTML element or attribute, do it. - straight from the w3c
"ARIA roles add nothing to default semantics of most elements" - Steve Faulkner (source )
Don't add default implicit roles to elements
❮button role="button" ❯ button text ❮/button❯
Don't add ARIA state or property attributes in addition to their native HTML counterparts
❮input type="text" required aria-required="true" ❯
❮div hidden aria-hidden="true" ❯
Don't add ARIA roles and states or properties to long-implemented structural elements
❮h1 role="heading" aria-level="1" ❯heading text❮/h1❯
New(ish) HTML5 Elements with default implicit semantics
What this means is that, where implemented , the browser will expose the default implicit semantics of the element so you don’t have to.
❮header❯ maps to role="banner"
❮nav❯ maps to role="navigation"
❮main❯ maps to role="main"
❮section❯ maps to role="region"
❮article❯ maps to role="article"
❮aside❯ maps to role="complementary"
❮footer❯ maps to role="contentinfo"
New(ish) HTML5 Elements: Browser Support
New(ish) HTML5 Elements: Browser Support
BUT IE and Safari do not offer support for all of the role mappings. -Deque University
USE it for Landmark Roles
❮header role="banner"❯
❮nav role="navigation" ❯
❮main role="main" ❯
❮footer role="contentinfo" ❯
Read List
Now that we understand ARIA, let's start auditing!
2. W3C Validation
Note - conformance checking
We test using the w3c validator.
this one step will catch a multitude of sins
W3C Validation
Notes on conformance checking
Warnings vs Errors
Errors - required to fix to validate
Warnings - are more of you may or may not need to fix -> more of a recommendation
3. Semantic HTML
Headings
are meant to help users understand content hierarchy
levels should not be skipped (BAD - h1, h2, h4)
Links, Buttons, Divs and Spans
Links - are being styled like buttons, which is fine. Just don't mark them up as buttons.
a, div and span ARE NOT buttons Products
if it acts like a button, make it a button
When you validate your site via W3C, you'll catch embarrassing errors like unsemantic html
Heading tags are for content hierarchy (outline), not for styling
If you want an h3 to look like an h4, style it with CSS, but don't skip heading levels.
If you don’t like how a button or link looks, style it with CSS.
If it navigates, it is a link. Use link markup with a valid hypertext reference
If it triggers an action, it is a button. Use a BUTTON
element
DIV
s and SPAN
s are not buttons
and are not natively supported to have keyboard focus, name, role, or value ... why use them and have to add all of this support via more code?
4. Focus Management (aka - Keyboard Accessibility)
Tabbing. Does it: Highlight what it's on?
Do NOT remove the default :focus { outline: none; outline: 0; }! Update the css if you do not like how it looks, but do not remove it! It is imperative for ppl that nav via keyboard to see what the focus is on.
PLAY VIDEO!!!!
Does it: Jump somewhere unexpected?
Do you have to go through the main nav?
Add a skip nav (and make sure it works!) -- add tabindex=-1 to elements you want to be focusable, but not in the normal tab order
Provide a skip nav
Add a skip nav (and make sure it works!) -- add tabindex=-1 to elements you want to be focusable, but not in the normal tab order
Provide skip to page sections
5. Accessible SVGs
Pixels, My Super-friendly Cat
An illustrated gray cat with bright green eyes that is waving it's tail.
Pixels, My Super-friendly Cat
An illustrated gray cat with bright green eyes that is waving it's tail.
...
Use inline SVG (in the html)
Provide a title (must be the first child of its parent element)
Provide a description
link the title and description with aria-labelledby="title desc"
Use text - because it makes text in graphical content highly accessible.
6. Accessible Canvas
text inside of a canvas element
text inside of a canvas element with paragraph tag
text inside of a canvas element
text inside of a canvas element with paragraph tag
When using canvas you must provide content that conveys the same function/purpose as the bitmap canvas.
It can be as simple as providing text in the canvas. The text is not visually seen, but is read via the screen reader.
Off Screen Text
//hiding text elements from the view, but keeping them available to the screen reader
.sr-only {
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);
clip-path: polygon(0px 0px, 0px 0px, 0px 0px, 0px 0px); //for clip being deprecated
}
7. Functional and Logical Forms
Add Automated Testing:
NPM: https://www.npmjs.com/browse/keyword/a11y
Gulp-a11y Grunt-a11y Tenon Ember React
pa11y (dashboard): http://pa11y.org/
pa11y http://pa11y.org/