Laughlin Constable Web Accessibility Basics for Web Developers
- 3. Why make your site accessible?
- 4. Disability Types 4 57 Million Americans are living with a disability
- 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
- 9. 9
- 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
- 20. Questions? 20
Editor's Notes
- #3: 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.
- #5: 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.
- #6: 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.
- #7: 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.
- #8: 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.
- #9: 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.
- #10: 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
- #11: read before: Here some key principles for developers to keep in mind. The next several slides demonstrate these key principles in more detail.
- #12: 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”
- #13: 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.
- #14: 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.
- #15: Tabbing through links will read just “learn more”.
- #16: Some of our CSS resets remove the outline property on focus. If your reset has removed that property, be sure to redefine the style.
- #17: 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
- #18: 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.
- #19: 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.
- #20: 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.
- #21: 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.