This presentation goes into the why, what and how to ensure your website is accessible to those with disabilities. It is geared towards web developers but project managers, account managers, user experience, creative designers, strategists, quality assurance and analytic teams are sure to learn a thing or two.
5. 1. It’s Morally Right
5
2. Economically Smart
3. It’s The Law
6. • Almost all disabled users are unable to use a mouse.
• They use the keyboard to navigate and a screen reader to read the
information to them.
• Could you successfully navigate around a site you’ve worked on without a
mouse?
Independence
6
7. • 37% - Lack of awareness
• 36% - Lack of skills or knowledge
• 13% - Hinders design
• 14% - Budget
Reasons for Inaccessibility
7
36%
37%
13%
14%
8. Navigating Content
• One way is to use Tab and Shift+Tab to
jump around focusable elements.
• Another way is to jump from heading to
heading.
• They can navigate via ARIA Landmarks
and HTML5 Sectioning elements
<section> <main> <nav> <footer>
<article>
Screen Readers
8
Reading Content
• They read alternative text on images.
• Pronounce acronyms like words if there are
sufficient vowels/consonants. Otherwise,
they will spell out the letters.
• Some browsers seem to work better with
certain screen readers.
• Firefox with NVDA
• Chrome or IE with JAWS
• Safari with VoiceOver
• Edge with Narrator
10. • Properly written alternative text
• Proper document structure
• Clearly written forms
• Focus states on links
• Ensure links make sense out of
context
• Don’t rely on color alone to convey
meaning
• Allow users to skip repetitive
elements on the page
• Ensure the page doesn’t require
JavaScript to function
• Use ARIA (Accessibility of Rich
Internet Applications)
• Provide headers for data tables
• Caption and/or provide transcripts
for media
Key Principles for Developers
10
11. Alternative Text
• Use as few words as possible
• Don’t include the words “Image of”
• Don’t include the word “logo” if it is
a logo
• Don’t repeat text associated with
the image
• Good SEO side effects
11
12. Document Structure
Headings, lists, and other structural elements provide
meaning and structure to web pages.
• Heading structure should be in hierarchical manner.
Don’t skip heading levels.
• User proper HTML5 tags <section> <header>
<main> <nav> <footer> <article>
• Missing headings are OK. Heading structure is more
important that document structure.
12
No Heading Needed
<main>
<h6
class=“assistive-
text”>Main Content</h6>
</main>
Screen Reader Reads:
“Main Placeholder, Main
Content”
13. Forms
Forms should be clear and intuitive and provide clear instructions about what
information is needed.
• Ensure that every form is accessible using the Tab key.
• Associate all labels to fields.
• * Required fields are clearly indicated.
• Errors are presented in an efficient, intuitive, and accessible manner.
13
14. Links
Every link should make sense if the
link text is read by itself. Screen
reader users may choose to read
only the links on a web page.
Certain phrases like "click here"
and “learn more" must be avoided.
• Developers are responsible for
adding hidden descriptive text.
14
<a href=“”>Learn More</a>
<a href=“”>Learn More<span
class=“assistive-text”> about
accessible links</span></a>
Screen Reader Reads:
“Learn more about accessible
links”
15. Link States
The focus state should be visually
prominent (an outline, underline or
color change).
15
:focus { outline: none; }
Don’t Do It!
(if you do, make sure you redefine it)
16. Skip Links
Provide a skip to content link at the top of the page that jumps to the main
content of the page (Hero).
16
17. Color
The use of color can enhance
comprehension, but do not use
color alone to convey information.
That information may not be
available to a person who is
colorblind and will be unavailable to
screen reader users.
17
18. Contrast
Web Content Accessibility
Guidelines requires that the
foreground and background colors
have a 4.5:1 contrast ratio to pass
the lowest level (Level AA) and a
7:1 contrast ratio at Level AAA.
18
19. Correctly Used:
• Interactive controls (menus, sliders, accordions)
• Dynamic content that may change within a page (AJAX)
• Error messages on forms
Incorrectly used:
• Correcting HTML semantics.
Use <button> instead of <div role=“button”>
WAI-ARIA Authoring Practices: https://www.w3.org/TR/wai-aria-
practices/
ARIA (Accessibility of Rich Internet Applications)
19
Common Widgets
Accordions
Breadcrumbs
Buttons
Mobile Menu
Popups
Sliders
Tabs
Tooltips
Today I’m going to teach you the basics of Web Accessibility. I’m just going to scratch the surface and hopefully get you interested in learning more.
I want you to understand how people with disabilities use the web, the frustrations they feel when they cannot access the web, and what you can do to make your sites more accessible.
Because there are 57 million Americans who are living with a disability and most of them can’t use a mouse.
To understand what its like having a disability, try navigating through the web using only your keyboard.
Everyone should have equal access to the information on the Web.
You could be preventing some users from purchasing products, signing up for paid classes or finding a doctor.
We have civil rights legislation, the American's with Disabilities Act, the Reauthorized Rehabilitation Act, the Telecommunications Act. They all support the fact that people should have equal access to the information that's on the Web.
People with disabilities want to be independent.
Imagine trying to navigate around a site you’ve never seen with your eyes closed. You would need someone to help you read it. Or you could use a screen reader.
The main reasons why sites are not accessible is due to lack of awareness and knowledge. This goes for the client as well as the agency. We should be educating our clients of the importance. Medela is a prime example. We have asked them many times if they wanted to make their site accessible but they refused. I’m guessing because of budget. They are now bing forced to update their site to comply with AA standards. Which will now cost more money.
Let me help you understand how screen readers work. They present content to users one item at a time. This is the opposite way in which sighted people use the web. We can scan an entire screen instantly, comprehending the overall layout and design. Screen reader users can’t comprehend these aspects as quickly. They read content in a linear fashion from beginning to end. It’s like an automated telephone menu. Where you have to wait to hear all the options before you make your selection.
It’s important to note that each screen reader navigates in different ways. These differences don’t typically impact coding practices. The key is to adhere to accessibility standards and generally-accepted accessibility techniques.
I’m to show you a 6 and a half minute video demonstrating three people who have difficulties using the web. Warning this is really old but a lot of the problems these individuals faced back then are still a problem today. Start at 2:00
read before: Here some key principles for developers to keep in mind. The next several slides demonstrate these key principles in more detail.
Alternative text provides a textual alternative to non-text content. Those who are blind and rely on a screen reader, need to have the image described to them.
GOOD “Stack of blueberry pancakes with syrup and powdered sugar”
BAD “Image of pancakes”
Its important to think about document structure when viewing wires and creative. That way you can point out red flags that may hinder proper document structure before development starts to content strategy, ux and creative teams.
The reliance on headings is the predominant mechanism for finding page information. **Don’t skip heading levels.
Screen readers will read the HTML5 tags out loud. the <main> tag is read “Main Placeholder”
So if you have an <h6> titled “main content” inside the <main> tag the screen reader will read “Main Placeholder, Main Content”. That is redundant.
It’s okay to exclude headings. Heading structure trumps document structure. We will touch more on that in our FE Dev meeting.
read before:
Forms should be clear and intuitive. Screen reader users generally navigate through a form using the Tab key to jump from form control to form control. Form labels are read for each form control when the user navigates to them.
A Required label will read “asterisk” required or “star” required. Insert asterisk outside label.
The error is clearly identified, put focus on the first error field so the user can easily fix the error and resubmit the form.
Tabbing through links will read just “learn more”.
Some of our CSS resets remove the outline property on focus.
If your reset has removed that property, be sure to redefine the style.
We add a skip to content link so users can skip all the navigation. This is typically used when the user has been to the site before or has navigated deeper within the site.
Consider users with no arm movement. They use computers by tapping their heads on a switch or some use a stick in their mouth to select keys. Requiring users to perform any action multiple times before reaching the main content is unacceptable.
Demonstrate ThedaCare - tab through links
Red-Green deficiencies are the most common.
Reds look more like beiges and appear darker than they actually are.
Greens look similar to the reds.
You can use a contrast checker tool to determine what the ratio is between any foreground and background color.
here you can see the contrast ratio of LC’s brand colors.
The pink ratio is 6 to 1 so it passes AA.
AAA is almost impossible to attain.
The yellow contrast ratio is only 1.4 to 1.
ARIA can enhance accessibility when used correctly. However, some ARIA attributes are typically used in ways that cause more problems than they solve. Most problematic ARIA attributes are often used to override correct HTML semantics and thus present incorrect information or interactions to screen reader users.
Be very careful when using ARIA. If you are in doubt regarding the correct implementation of ARIA, the first place to look is the WAI-ARIA Authoring Practice, especially the section on Design Patterns and Widgets. This section outlines the correct patterns for over 20 common ARIA widgets.
Now you understand how people with disabilities use the web, the frustrations they feel when they cannot access is, and what you can do to make your sites more accessible. By no means am I an expert, I’m constantly learning more about accessibility and the standards are constantly changing.
Do you have any questions?
resources:
webaim.org, (Web with Accessibility in Mind)
https://www.w3.org/WAI/intro/wcag Web Content Accessibility Guidelines (WCAG). The guidelines can be complicated though. They are filled with grey areas and things change as technology changes.