Accessible websites: Complete checklist for site owners

A deeper dive into web accessibility

• Web accessibility  = "the ability to access" for everyone. Having an accessible website is about providing equal access and opportunity to people with physical and situational disabilities. It also extends to those with socio-economic restrictions on speed and bandwidth and people who prefer mobile devices over desktops and vice-versa.
• It doesn't just benefit people with disabilities . While features for auditory support or color contrast may be meant for users with disabilities, things like mobile optimization and clear navigation benefit everyone.
• Your clients' sales are on the line . According to the World Health Organization,1.3 billion people around the world experience a significant disability. Without an accessible website, as many as 1 in every 6 site visitors won't even have the opportunity to become customers.
• Failing to meet accessibility requirements costs them dearly . Not only will your clients potentially face lawsuits and settlements, but they'll also lose credibility and trust from customers if their website is inaccessible. When you factor in lost sales, diminished public image, and potential lawsuits, you're looking at a six-figure loss.

Why is website accessibility so important for agencies?

• Market your sites as "accessible" to future clients
• Enhance the user experience and maximize conversions
• Protect yourself and your clients from accessibility-based lawsuits
• Improve SEO performance through accessibility features
• Boost your agency's reputation and credibility

Be prepared to answer clients' questions regarding accessibility.

• The # of critical accessibility errors currently live on their site
• The tools you use to assess the UX for accessibility errors
• Which accessibility standard(s) your team evaluates against (A, AA, or AAA)
• How you approach web accessibility when designing an eye-catching website
• Your process for creating accessible content (alt text, captions, transcripts, etc.)
• How do you monitor accessibility over time
• How you collect and incorporate feedback from various user groups into future UX iterations

Be prepared to explain the importance of accessibility to clients who object.

• "Nobody's ever complained about our site before."
• "People with disabilities don't buy what we sell."
• "We don't have the resources for this right now."
• "It's just going to make our site look boring."
• "We already use an AI-powered overlay."

• Most people aren't going to tell the site owner their site's inaccessible. They'll just leave. Or, the site could be so inaccessible nobody can even reach the "Contact Us" page or email form.
• Blind people might not purchase flying lessons for themselves, but they might for a friend.
• The potential loss from an accessibility lawsuit is significantly higher than the cost of creating an accessible site. And if they're an ecommerce client, they're disproportionately at risk.
• You can make a site accessible without changing the core design.
• According to UsableNet's abovementioned report, there were 414 lawsuits filed against companies using overlays or active widgets.

The legal aspect: accessibility guidelines, regulations, and standards

Section 508 of the Rehabilitation Act (1998)

Health Insurance Portability and Accountability Act (HIPAA)

WCAG levels: A, AA, AAA

• Level A (minimum level): The most basic web accessibility features must be implemented. Failing to satisfy this level would make it difficult for many people with disabilities to access the content.
• Level AA (mid-range): Addresses the biggest barriers for disabled users, and is generally aimed at improving accessibility for all. It is also the level most often referenced in legislation and policies.
• Level AAA (highest level): The most complex level of web accessibility, level AAA improves the experience for users with a wider range of disabilities. This level is not required by most policies but is good practice to aim for if possible.

POUR principles

• Perceivable: Information and user interface components must be presentable to users in ways they can easily see.
• Operable: UI components and site navigation need to be functional and easy to operate.
• Understandable: Information and the operation of the user interface must be understandable.
• Robust: Content must be well-written and structured enough that a wide variety of users and assistive technologies can interpret it correctly.

WCAG 2.1 and 2.2

WCAG 2.1 enhancements

• Mobile accessibility: New guidelines were introduced to improve access for mobile and touch-screen device users. This includes making functions accessible from a keyboard and ensuring that users can use devices in any orientation (portrait or landscape).
• Low-vision support: Improvements were made to support users with low vision, such as requirements for text spacing and non-text contrast, which help ensure legibility and readability.
• Cognitive disabilities: New criteria aimed to help users with cognitive, learning, and neurological disabilities, offering more ways to find content and making it easier to use inputs other than keyboard.

WCAG 2.2 additions

• Findable help: This criterion requires that help be available on a website, such as human contact information, self-help options, and automated help, which is especially beneficial for users who may struggle with navigation or complex information.
• Consistent help: Ensuring that help options are available consistently across different web pages.
• Accessibility of personal information: Guidelines that help users with cognitive disabilities by simplifying the process of entering personal information and correcting mistakes.

ADA compliance

European Accessibility Act (EAA)

The complete website accessibility checklist for agencies

1. Ensure color contrast ratios.

• When designing elements like buttons or graphical controls, test the foreground/background on those elements before implementing them on the website.
• Ensure that contrast remains sufficient even in dark mode or high-contrast settings, as some users may rely on these for better visibility.

2. Make sure your client’s website is keyboard accessible.

• Make all interactive elements, including links, buttons, and form inputs, able to be selected, focused, and activated using the keyboard, typically with the Tab, Enter, and Space keys.
• Avoid keyboard traps where a keyboard user cannot move focus away from an interactive element without using a mouse. Users should be able to navigate through all page elements using standard keyboard commands and exit any focused element.
• Provide visual indicators such as outlines or highlights when interactive elements gain focus to help users identify their location on the page.
• Make all windows closable using the Esc key; for example, when using modal windows or lightboxes.
• Include scrolling functionality using the arrow keys.

3. Avoid flashy designs.

• Use tools like thePhotosensitive Epilepsy Analysis Tool (PEAT) to test content for seizure risks.
• Avoid elements that flash or flicker faster than three times per second.
• Ensure that any flashing content does not exceed the general flash and red flash thresholds, which are particularly triggering.
• Provide mechanisms for users to stop, pause, or hide flashing or blinking content, especially for auto-playing videos or animations.
• For emergency alerts, use a gentle fade-in effect instead of flashing, adhering to the threshold guidelines.

4. Provide unique page titles.

• Ensure each page title describes the main content or purpose of the page. This helps users navigate through tabs and understand the page content at a glance.
• Each title should be unique within the website to avoid confusion and help users distinguish between different pages when multiple tabs are open or when using history navigation.
• Titles should be concise and prioritize the most important information. Placing unique and relevant information first in the title (front-loading) can be more helpful, especially for users who rely on screen readers.
• Avoid generic titles like "Products" or "Services," which do not provide specific information about your client’s page content.

5. Organize your content.

• Use <header> for introductory content or navigational links and <footer> for information about the author, related documents, and copyrights.
• Use <nav> for major navigation blocks, such as primary site links, which can be easily located by screen readers.
• Use <article> for self-contained compositions that can be independently distributed or reused, such as blog posts or news articles.
• Use <section> to define sections within a document, like chapters, headers, footers, or any other sections of the document.

6. Provide captions and transcripts for videos.

• For pre-recorded content, provide closed captions that can be toggled on and off. Ensure captions include not only dialogue but also other audio cues like sound effects and music when they are essential for understanding the content.
• For live content, use real-time captioning services.
• Transcripts should include detailed descriptions of all significant audio and visual content, not just dialogue. This might include descriptions of actions, facial expressions, background noises, and scene changes.

7. Include labels for form elements and inputs.

• Proper labeling: Every input in a form should have a corresponding label element that defines the purpose of the input field. This is achieved by ensuring the for attribute of the label matches the id attribute of the input element, creating a programmatically determinable relationship between the label and the specific input.
• Visual design and CSS: While CSS can be used to visually enhance or hide labels for aesthetic purposes, it's crucial that the labels remain functionally accessible to all users, including those using assistive technologies. Techniques like "screen reader only" classes can be used to hide labels visually while keeping them accessible to screen readers.
• Placeholder text vs. labels: It's a common misconception that placeholder text can replace labels. However, placeholders disappear when the user starts typing, which can confuse users who might forget what information belongs in the field. Placeholders should be used to provide an example of the type of input required, not as a substitute for labels.
• Semantic HTML: Use semantic HTML5 elements like <label>, <input>, <textarea>, and <button> correctly to ensure they provide the necessary accessibility features inherently supported by browsers and assistive technologies.

8. Give additional options when users make mistakes.

• Errors should be immediately noticeable and clearly explained. Positioning error messages at the top of the form and providing in-page links directly to the erroneous fields can help users quickly understand and rectify issues.
• Include clear descriptions of what the error is and how to fix it. For example, instead of simply saying "Invalid entry," specify "The Date field is in the wrong format; it should be DD/MM/YYYY."
• Use visual cues like color changes alongside programmatic changes such as ARIA labels to indicate errors. However, ensure these cues are not solely visual as this does not accommodate all users.
• Provide real-time validation that alerts users to errors as they occur. This approach helps prevent errors before form submission, enhancing the user experience by reducing the need for error correction post-submission.
• Use JavaScript and ARIA. Utilize JavaScript for dynamic error handling and ARIA properties to link error messages directly with the form inputs they relate to, improving accessibility for screen reader users.

9. Provide easy-to-identify links.

• Use styles that differentiate links from regular text (underlining works best because most people know an underline indicates a link). Ensure that these styles are consistent throughout the site.
• Use descriptive text that provides clear information about the destination of the link. Avoid vague text like "click here" or "more", which does not provide information about the link’s purpose.
• Color should not be the sole method of identifying links; instead, it should be used alongside other indicators. For users who are color blind, relying on color differences alone to distinguish text can lead to usability issues.
• For links that contain icons or images, use ARIA labels or alt text to clearly describe the action or destination of the link.

10. Provide options for navigation.

• Include multiple ways to navigate the site, such as menus, search functions, site maps, and tables of contents. This variety helps cater to different user preferences and accessibility needs.
• Use semantic HTML elements like <nav> for navigation sections, and properly mark up lists within navigation menus using <ul> or <ol> depending on whether order is relevant. This structure aids assistive technologies in understanding and interacting with the site layout.
• Provide "skip to main content" links at the beginning of pages to allow users to bypass repetitive navigation links. This feature is especially useful for those using screen readers or keyboard navigation.
• For dropdowns and fly-out menus, ensure that all users, including those who navigate by keyboard, can access all items. Menus should be operable with both mouse and keyboard interfaces, and should not require specific timings for mouseovers, which can be challenging for users with motor impairments.
• Use methods like ARIA labels or visual cues to indicate the current page or section within navigation menus. This helps users understand their current location within the site structure, which is crucial for orientation.

11. Provide feedback and write useful error messages.

• Use live regions in your HTML to alert screen reader users immediately when errors occur. This method informs them about errors without needing to change the focus or reload the page.
• Include specific instructions on how to fix the errors. For example, if a required field is empty, the error message should state which field is affected and what is expected (e.g., "The Date field is required and must be in the format DD/MM/YYYY").
• Ensure that error messages are accompanied by both visual cues (like icons or different text colors) and programmatically determined markers (such as using aria-describedby) that assistive technologies can convey to users.
• Use inline validation to provide immediate feedback as users fill out forms. This helps prevent errors by confirming correct entries as soon as they are made and providing tips or corrections before the user moves on to the next field.
• Position error messages right near the form fields they relate to, or list all errors at the top of the form with links that take users directly to the erroneous fields. This helps users identify and correct multiple issues more efficiently.

12. Build responsive sites.

• Use fluid grids that use relative units like percentages rather than fixed units like pixels. This flexibility allows the content to expand or shrink to fit the screen size.
• Ensure images and other media content resize within their containing elements. The use of CSS techniques such as max-width: 100% can keep images from extending past the screen width.
• Use media queries to apply different styling rules based on the device characteristics, such as its width, height, and orientation. This allows for precise control over how content is displayed on various devices.
• Use the viewport meta tag to control layout on mobile browsers, setting parameters for width and initial scale to enhance user experience.
• Ensure navigation menus are accessible, with adequate tap targets and keyboard navigability, to accommodate touch and non-touch users alike. Also make interactive elements like buttons and links large enough to be easily tapped on a touchscreen device.
• Avoid fixed positioning. Fixed UI components can interfere with zooming and scaling on small screens, so it’s better to use static or relative positioning.

13. Include headings and spacing.

• Use headings hierarchically from <h1> to <h6>. The <h1> should always be the main title of the page, and subsequent headings (<h2>, <h3>, etc.) should denote sub-sections within the document in descending order of importance.
• Ensure that headings are descriptive and provide a clear indication of the content that follows them. This assists in making the content more navigable and comprehensible, particularly for users who rely on assistive technology.
• Avoid skipping heading levels (e.g., going from <h1> straight to <h3>). This can confuse both users and assistive technologies. Maintaining a logical order helps in creating a coherent flow of content.

• Follow WCAG guidelines which recommend a line height (line spacing) of at least 1.5 times the font size, and spacing following paragraphs of at least 2 times the font size. Letter spacing (tracking) should be at least 0.12 times the font size, and word spacing at least 0.16 times the font size.
• Make sure these spacing settings allow for content to be readable even when text size is increased by up to 200%.

14. Add alt text to images.

• Avoid unnecessary words like "image of" or "picture of." The description should be informative and context-relevant without being overly detailed, aiming to keep under about 125 characters to avoid being cut off by some screen readers.
• Tailor the alt text to reflect the image's role within its accompanying content. For example, the description for an image used in a technical article would differ from that of the same image used in a casual blog post.
• Avoid decorative text for purely decorative images. If an image is only part of the site for show, use an empty alt attribute (alt="") to avoid cluttering screen reader output with unnecessary descriptions.
• Include keywords for SEO. Incorporate relevant keywords in the alt text to enhance the image's visibility in search engine results. However, ensure these keywords are naturally integrated and relevant to the image.
• Maintain a neutral and objective tone. Refrain from subjective interpretations of the image unless it directly relates to the content's message.
• For complex images like charts or graphs, consider using a brief alt text combined with a more detailed description close to the image or in a linked detailed description page.

15. Provide accessibility audits for clients.

• Check color contrast. Use a contrast checker tool to ensure that the foreground and background colors have sufficient contrast for readability.
• Test keyboard accessibility. Use only the tab key to navigate through elements on the page, and make sure all interactive elements can be reached with the keyboard alone.
• Review alt text for all images. Ensure that descriptive and relevant alt text is provided for all images in the site.
• Check for proper headings structure. Inspect each page to make sure headings are used hierarchically, and they accurately reflect the content on the page.
• Test with a screen reader. Pay attention to any issues that may arise and make necessary fixes.

16. Provide controls for auto-playing content.

1. Ensure all media controls for auto-playing content are visible and accessible to all users, including those who rely on keyboard navigation and screen readers.
2. Avoid auto-playing significant audio content, and consider the implications for users with different needs. If auto-play cannot be avoided (e.g., for a SaaS website demoing a product), make the "pause" and "stop playback" controls immediately available.
3. Regularly test these controls to ensure they work correctly across different devices and browsers. This includes checking their functionality with assistive technologies like screen readers.

• Use automated tools. There are many online tools available that can scan your clients' websites and identify any potential issues with accessibility. Some popular options include the WAVE Web Accessibility Evaluation Tool, Lighthouse (in Chrome DevTools), and Axe Testing Tools.
• Test with a screen reader. Using a screen reader allows you to experience the website as someone with visual or cognitive impairments would. Common screen readers include NVDA and VoiceOver.
• Conduct manual checks. While automated tools and screen readers can catch many accessibility issues, it's also important to do manual checks for common problems like color contrast, keyboard accessibility, and heading structure.
• Include users with disabilities in testing. Invite individuals with disabilities to test the website and provide feedback on different elements.
• Gather feedback from diverse user groups. When assessing site accessibility for your clients on an ongoing basis, it's important to gather feedback from diverse groups of users. This could include individuals with different types of disabilities, individuals with varying levels of technical expertise, and individuals using different assistive technologies.