https://github.com/fpapado/gaad-2019-presentation
Around 80 million people in the EU are affected by a disability in some degree (temporary / permanent disability).
- EAA Factsheet
Disabled people make up 1/6 of the working age people in Europe.
- EU department of Employment, Social Affairs & Inclusion
On average in the EU-27, only 5% of public websites comply fully with web accessibility standards, though more are partially accessible.
- European Disability Strategy 2010-2020: A Renewed Commitment to a BarrierFree Europe
- The quality of being able to be reached or entered.
- The quality of being easy to obtain or use.
- The quality of being easily understood or appreciated.
In the digital world, accessibility covers more areas than one would think, these include: Performance, Design, Implementation of code, Copywriting Legal, Diversity and Inclusion
Major categories of disability:
- Visual (Blindness, low vision, color-blindness)
- Hearing (Deafness and hard-of-hearing)
- Motor (Inability to use a mouse, slow response time, limited fine motor control)
- Cognitive (Learning disabilities, distractibility, inability to remember or focus on large amounts of information)
Source: https://webaim.org/intro/
Many of these can be:
- Permanent (e.g. if you are born or become permanently blind)
- Temporary (e.g. an arm in a cast, eye surgery)
- Situational (e.g. holding a baby, being under stress)
Guidance to making sites accessible: POUR
- Perceivable
- Operable
- Understandable
- Robust
- It's a numeronym, that stands for Accessibility
- Pronounced "accessibility"
- A ...(11 letters)... y
- Easy to google/search in hashtags
- Latest version 2.1
- A set of criteria and, well, guidelines
- Different levels of compliance (A, AA, AAA)
- Aim to address real issues
- ...don't think of it as just "a spec"
Knowing what / who to ask, is more important than how to solve it
- Responsive Web Design and mobile-first approaches work great for zoom-levels. A "desktop" 400% zoom might as well be a short "mobile" screen!
- Similar points for fixed elements; prefer flexible layout methods & designs
- Colour contrast
- Heading levels
- Form labels
- Underlines on links
- Do not remove focus outlines
- Design systems as an opportunity
- Responsive Web Design (in the implementation and communication)
- Semantic HTML; headling levels increase logically, lists, forms, inputs, buttons
- Communicating error states
- Any of the notes in the design section above :)
- Exposing the correct widget roles and behaviour
These are some things I find
- From Design: User research! Intentionally designing stats.
- From Development: Communicating the constraints and possibilities of layout; emphasising the required semantic promises (headings, labels etc.)
- Having a shorter feedback loop
- Auditing a site live
- Going over references
- Reading an audit
- Having a Q&A
- Way to keep track of progress
- However, not the actual guidelines
The following is NOT the Web Content Accessibility Guidelines (WCAG) 2. It is a checklist that presents our recommendations for implementing accessibility principles and techniques for those seeking WCAG conformance. The language used here significantly simplifies and condenses the official WCAG 2.1 specification and supporting materials to make it easier to implement and verify for web pages.
- You can only catch 20-40% of issues
- AxE from Deque - AxE Plugin
- Accessibility Insights. Has a great "manual" mode.
You can get these in CI:
...what does "in CI" mean, though?
- Testing vs. Monitoring; building a backlog
- Audits are a great way to find issues, keep a holistic overview, as well as learn things
- Evaluation by pattern vs. by principle
A shared pain is half the pain, a shared joy is twice the joy
- Always write things down
- Agree that it's the focus
- Ask questions
- Knowing what / who to ask, is more important than how to solve it
- The sort of thing you could do in issues/PRs
- Share references
(Internal links)
- PR templates
- e.g. with Inclusive Design Principles, or POUR, or...
- Walk through with someone
- Someone dedicated / delegated to check accessibility
As you incorporate accessibility into your workflow, you develop an intuition for these things
- Semantic HTML
- Color contrast
- Labels
- Click handlers on non-buttons
- Document hierarchy (h1-h6)
- Identifying roles/widgets
- Visual/source order mismatch (absolute positioning, flex order etc.)
- Routing
From the HTML Design Principles:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity
Web Content Accessibility Guidelines (WCAG) 2.1
ARIA Authoring Practices How to work with ARIA, how to implement speicfic patterns. For example, a combobox, a modal, a carousel. Also, illustrate how much semantic HTML gives you by default.
Inclusive Design Principles. Series of principles that are meant to promote good practices. Great to print out and have as a reminder, and to help establish a common ground.
HTML Accessibility API Mappings. Ever wonder why we say "semantic HTML is better for accessibility"? This document establishes what role, label, and state each semantic HTML element exposes by default!
A11y Project. A lot of resources on Accessibility.
Inclusive Components. A "blog aiming to be a pattern library", great breakdown of custom widgets and considerations. Also as an ebook.
Accessibility For Everyone. Great insight into the reasons, processes and implementation of accessibility.
How A Screen Reader User Accesses The Web: A Smashing Video. Léonie Watson goes over how she browses, and various modes in screen readers.
Udemy: Web Accessibility, by Google. Short, fairly comprehensive insight into practical accessibility. Give this a watch!
Deque University. Longer-form, self-paced courses. Intended to develop expertise and prepare for certification. Useful to have someone with that knowledge on the team.
I think one of the best ways to learn, is to read audits. They show how accessibility is an ongoing process. One I like in particular is the Bulb Inclusive Design Audit.
Entirely not comprehensive list: