- [Accessibility for everyone - Laura Kalbag](#accessibility-for-everyone---laura-kalbaghttpsabookapartcomproductsaccessibility-for-everyone)
- Book review
- 4. Content and design
- 5. Accessibility and HTML
- The importance of structure
- Keyboard navigation
- Separating structure and style
- Progressive enhancement / graceful degradation
- 6. Evaluation and testing
- 7. Laws and guidelines
- Emphatically written
- Gives a great idea how you can start making products more inclusive right now
- Also gives a serious roadmap on how to work on accessibility in a team
- Functional / technical advice in chapter 5 and 6
- Often a11y features that seem to be meant for people with a specific disability benefit others as well. For example, when I watch Netflix I turn on subtitles in the same language. These subtitles might be intended for people with a hearing disability, but come in mighty handy when there's a lot of noise around. The point is, a11y features don't just improve your app for a specific group, it improves it for everyone.
- Content creators should also be educated in making content accessible
- divide text
- use alt text
- descriptive links
- When you update content with a non-user event (i.e. server request) it's important to notify the user. How do you handle screen-readers for example?
- Color should never be used as the sole means of conveying information.
“Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.
Excerpt From: Laura Kalbag. “Accessibility for Everyone.”
Both OS/X and Windows come with their own screen reader. OS/X has VoiceOver and Microsoft has narrator. If you want to test a site with a screen reader, these can be quickly enabled.
- JAWS (Expensive)
- VoiceOver (Apple / OS/X)
- NVDA - NonVisual Desktop Access
- Microsoft Narrator - Windows
- Wikipedia screen reader list
4. Content and design
In the rich web apps we create today, content can change without it being triggered by a user event. In this case users should be alerted of the change. Screen readers should be updated of the state change as well. Twitter is a good example of how this is done.
Error messages should be expressive and make use of 'human language'.
Color should never be the sole conveyor of information on the web, not even if it should actually convey a color. If you have a product with only color swatches, these swatches might be meaningless for people who are colorblind or otherwise visually impaired.
All images that aren't decorative should contain an
alt text. The
alt text should be descriptive. For a picture of pancakes, an
alt text with 'Pancakes' is a lot less useful than "Stack of blueberry pancakes with powdered sugar". It will let someone with a screen reader know that this isn't JUST a stack of pancakes. source
Text in images
In general a bad idea. Unless it's a logo but in many cases you could use SVG text.
Machine learning for alt text?
Graphs and infographics
Think of a structured way to present the information to screen readers for example. Prevent a text alternative.
PDF's suck. The behaviour of clicking a PDF link is inconsistent across browsers and user settings. PDF's themselves aren't accessible.
Recreate PDF content in HTML to make it accessible and searchable. There are tools to do this automatically.
Use print stylesheets if content needs to be printable:
A generous user experience
Offering alternatives in your user interface is a great way to include more people. For example, having a video's transcribed will both help people with disabilities as attract people that prefer reading over watching.
5. Accessibility and HTML
The importance of structure
- Writing well structured HTML is the base of an accessible website.
- Check your HTML without any stylesheets and see if it makes sense. This is the raw content that screen readers go through.
- Googles design and content guidelines greatly match accessibility guidelines
- Using only one H1 on the page still seems like the way to go.
Screen readers will read out 'bullet' on an
ul or the number of an
ol item, even when these are hidden in CSS.
Overriding default form elements often results in loss of accessibility features.
All inputs have default accessibility features
Labels should not be omitted for placeholder texts. Labels are an important part of forms and make them descriptive and accessible.
Be clear if a form input is required. Adding an asterix to the label is good. Adding the word 'required' is better.
Label and input pairing
Each input should have a unique
ID and each corresponding label should have this
ID in it's form element. This pairs the input and label for screen readers, but also brings advantages for regular browsers. When you click a label, the matching input will automatically be in focus in most browser.
Make the different states distinguishable.
- Can be very helpful for people using screen readers. Check Twitter for a good example
- Used to quickly skip a bunch of links (we knew that)
- Often aimed at screen-readers and hidden off screen (we did that)
- Shouldn't be hidden because it's mostly useful for keyboard navigation
- The keyboard focus should also skip. This is not the default behaviour in Chrome and Safari at the moment
Keyboard focus and visual focus
- The visual focus is whatever is visible in the viewport
- Keyboard focus / element focus is the focus of a specific element
Focus and hover styles
- Links, buttons and inputs have a
tabindexand focus style by default
- Focus styles are indispensable when using keyboard navigation
- Don't rely on hover styles (mobile and such)
- Making a default
divinteractive can be confusing for screen-readers and user navigation (As reordering content with CSS for example)
tabindexis honored when navigating with the Tab button
tabindexis ignored when navigating with cursor keys
In general it's advisable not to change the tabindex
tabindex=0to tell keyboard navigation to recognize an element in the tab order. This can be used to make a (normally) non-interactive element reachable with the Tab button.
tabindex=-1to remove an element from the tab index. This can be used to fix the 'skip link'
The tabindex has it uses but is not totally reliable and only influences keyboard navigation.
Separating structure and style
- Often a culprit of bad HTML structure as they're made to change appearance, not structure
- Limit WYSIWYG editor options and instruct users
- Beware of re-ordering things with
css-gridas this is only applied with CSS and has no semantic meaning.
- Don't style an element to look like another one but use the element intended for the purpose (buttons/links/headers)
- Separate structure and style
- You can offer alternative styling for enhanced viewing options (think of Safari's 'Reader view')
Progressive enhancement / graceful degradation
- Progressive Enhancement: Start with the most basics, accessible to everyone and build up experiences from that point on
- Graceful degradation: Take the most capable browser as starting point and implement fallbacks
Stands for Web Accessibility Initiative - Accessible Rich Internet Applications. Often referred to as
ARIA is a relatively new standard (March 2014)
Allows developers to assign different roles, states and other properties to make it easier to describe their behaviour in HTML
Can possibly enhance the native meaning of HTML elements
- HTML attribute:
- Used to define page structure when HTML elements are not clear enough or to emphasize their meaning
- All about WAI-ARIA roles on w3c.org
- Don't tag
role=to just anything, make sure that it makes sense
Document landmarks are roles like
When you use HTML5 elements like
article, landmark roles are redundant (except for IE as it doesn't provide full accessibility support on HTML5 elements)
States and properties
Give information about the current state and content of a section/element
Are usually dynamic and can change throughout the use. i.e.
aria-expanded="false"to show if an area is collapsed or not.
aria-describedbycan tell assistive technology where to look for a description of an element (i.e. a password hint).
aria-livecan be used to make screen readers aware of content updates.
When to use ARIA (and when not to)
ARIA doesn't replace well structured HTML
ARIA won't make an unusable website usable
6. Evaluation and testing
Make A plan
- Create a test plan containing
- testing methods and when they'll be used
- how testing methods support production team towards targets
- how results are documented
- how results fit in the feedback loop
Heuristics and analysis
- Heuristic evaluations: Testing an interface against a set of guidelinces (WCAG)
- Cognitive walkthrough: Test the interface against specific tests, possibly emulating particular setups
- Don't wait with testing until the end.
- Possibly use something like Tenon API - https://tenon.io/
Device and browser testing
- Desktops running all major OS
- latest version of all major desktop browsers
- mobile devices running major operating systems (android is fragmented, use several versions)
- major browsers across mobile OS'es
- assistive technologies including screenreaders (JAWS, NVDU, oiceOver, Window-Eyes, Windows Narrator, ZoomText)
- Keybord navigation
- Accesibility settings like zoom and magnifiers
Validators and checkers
- "It's perfectly acceptable for your code to fail validation, as long as it fails for a good reason"
- W3C validator
- WebAIM's WAVE
Color and contrast checkers
- Google Lightouse does this
- Color Oracle
- See resources
Emulating connection speeds
Testing keyboard navigation
- Always include people with disabilities and impairments
- Choose testers that are comfortable in using the tools they're testing with (people who can teach you)
- Be careful about categorizing and grouping people with disabilities
- Testing deosn't end on launch day
- Consider adding form or feedback button
7. Laws and guidelines
European Accessibility Act
- How accessible is 'infinite-scroll' for adding new content? (or how could you make it accessible?)
Accessibility tools and websites
Articles on accessibility
- WAI-ARIA on MDN docs
- Aria Live regions on MDN
- All about WAI-ARIA roles on w3c.org
- List of landmark roles - WAI-ARIA
- Google Lighthouse
- WebAIM WCAG 2.0 checklist
- Pennstate Accessibility summart
- WUHCAG WCAG checklist
- W3.org Web accessibility evaluation tool list