Website Accessibility Checklist (15 Best Practices) | WebsiteSetup Skip to content Website Accessibility (15 Best Practices) Bruce Lawson Freelance accessibility consultant . He co-authored the books 'Introducing HTML5' and 'Web Accessibility'. When creating a website , there’s a lot of factors to consider. For example, it’s especially important to ensure your site is user-friendly for all people equally. This is where website accessibility practices come into action. So what exactly is website accessibility? It’s a practice of guaranteeing sites to be equally available to people with disabilities. Meaning, they will have similar access to the goods and services those sites provide. Website accessibility is an integral part of professional web design and development. In this guide, we will cover 15 of the most common practices that improve website accessibility. Why Should You Care About Accessibility? There are many reasons why developers, designers, and their employers/clients should ensure that accessibility is an early and integral part of the process of web development: In many territories, such as the USA, EU, UK, Israel, and Japan, it’s a legal requirement not to discriminate against people due to their disability. In the USA, 2,235 new ADA Website lawsuits were filed in federal court in 2019. That’s one per hour. Accessible sites tend to be better coded, more robust, and rank well on search engines. Inaccessible sites are bad for business. In 2019, a UK survey found that more than 4 million people abandoned a retail website because of the accessibility barriers they found. It’s bad business to voluntarily turn away potential customers. Most Common Errors on Top Million Home Pages We’ve looked at the top barriers to eCommerce sites as reported by users with some form of impairment. Now let’s look at a much broader set of sites— the home pages for the top 1,000,000 websites, automatically analyzed by WebAIM in August 2019. 98% of the pages analyzed had at least one error. The most common errors are Low contrast text (86.1%) Missing alternative text for images (67.9%) Empty links (58.9%) Missing form input labels (53.2%) Missing document language (30.5%) We’ve dealt with low contrast, links, and form inputs above. Now let’s look at how we can avoid the other very common errors. How to Improve Website Accessibility (15 Best Practices) It’s a checklist of the most common errors that people with disabilities say are their main blockers, with practical suggestions to resolve the problems. Firstly, note that none of the top 5 are technical issues — they’re a design or copywriting errors. 1) Too Much Content It’s well-known that as the number of choices increases, so does the effort required to collect information and make good decisions. It’s the same with too much content—it soon becomes overwhelming. So: Have only one
on a page. Use sub-headings liberally; it breaks up a ‘slab’ of text for sighted users, while users of assistive technologies such as screen readers can use a short-cut key to jump between headings or obtain a mental map of the content from the heading structure. Don’t skip a level of headings . For example, if you use an
, make sure it is preceded by an
. Use bulleted lists marked up correctly in HTML as
,
. Screen readers will announce “List of 10 items” (and allow the user to jump over them). Use Plain English Monzo Bank’s “Our tone of voice” guide explains the importance of plain language: In 2010, US attorney Sean Flammer ran an experiment. He asked 800 circuit court judges to side with either a traditional ‘legalese’ argument or one in what he called ‘plain English’. The judges overwhelmingly preferred the plain English version (66% to 34%), and that preference held no matter their age or background. Flammer notes (PDF) of the plain English version: It’s shorter by almost a page, so it obviously eliminates unnecessary sentences and words. Its sentences average 17.8 words, as opposed to 25.2 words. So basically, if you want to please your reader, write in plain English. In brief: break up text into sections with headings and bulleted lists. Use simple language. 2) ReCAPTCHA ReCAPTCHA is a free service from Google that helps protect websites from spam. It should be easy for humans to solve but hard for bots and other malicious software to figure out. However, the old reCAPTCHA version was something that many users were struggling with: Luckily the style of the wobbly letters of reCAPTCHA is now deprecated. It’s much more common to see a newer incarnation called “No CAPTCHA reCAPTCHA” (also known as the “ I’m not a robot” Checkbox ) which requires the user to check a box confirming they’re not a robot. If they pass, no further interaction is required. However, if they fail, a further challenge will be displayed: The most accessible form of reCAPTCHA is reCAPTCHA v3 which requires no user interaction, but needs you to do more work to deal with visits that fail the test: It is a pure JavaScript API returning a score, giving you the ability to take action in the context of your site. For instance requiring additional factors of authentication, sending a post to moderation, or throttling bots that may be scraping content. In brief: don’t make your users jump through potentially impossible hoops in order to save developer time. 3) Poor Readability Here are some of the best ways to make your text legible: Ensure adequate contrast . One of the most common access blockers on the web is the poor contrast between text and background. The W3C guidelines require a contrast ratio of at least 4.5:1, except for large-scale text and images of large-scale text which should have a contrast ratio of at least 3:1 (logos and ‘incidental’ text are exempt). There are many utilities that can measure contrast ratios for you; for example, Ada Rose Cannon’s contrast widget. Don’t have all-capital headings . There’s evidence that they are harder to read because capital letters are all the same height, so we can’t recognize the shape of common words. Additionally, some screen readers will spell out groups of capital letters as if they were abbreviations (like BBC, DOJ, etc). If you must have all capital headlines, write them in a normal case in your HTML and transform them with CSS text-transform: uppercase Left-align text . (For pages in right-to-left languages like Arabic or Hebrew, right-align text.) Don’t justify it, as this makes it harder for people with dyslexia to read. The British Dyslexia Association’s style guide also suggests using sans serif fonts, like Arial and Comic Sans, as letters can appear less crowded. Alternatives include Verdana, Tahoma, Century Gothic, Trebuchet, Calibri, Open Sans. In brief: make sure the text has adequate contrast, is readable, and isn’t justified. 4) Distracting Images and Graphics The most basic level of WCAG requires “For any moving, blinking or scrolling information that (1) starts automatically , (2) lasts more than five seconds , and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential”. Distraction is an annoyance – especially for people with ADHD or other cognitive impairments. But movement and flashing can also cause seizures, so the WCAG guidelines require that content should not flash more than three times in any one-second period. Respect User’s Choice for Animations All major operating systems allow the user to express a preference for reduced motion on-screen—perhaps because they have motion-triggered vestibular spectrum disorder. Your website can detect whether the user has done this with the CSS prefers-reduced-motion media query Here, we only allow a button to animate if the user has expressed no preference: /* @media (prefers-reduced-motion: no-preference) { button { /* `vibrate` keyframes are defined elsewhere */ animation: vibrate 0.3s linear infinite both; If you’re looking to retrofit a site that has many animation rules, the following may stop all previously declared CSS animations /* @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.001s !important; transition-duration: 0.001s !important; scroll-behavior: auto !important; The HTML picture element allows us to show a static image rather than an animated GIF to users who express the preference for reduced motion: /*
On the subject of respecting the user’s operating system preferences, you may want to consider designing your website for dark mode In brief: allow users to stop any movement; respect their operating system settings; don’t auto-play video. 5) Poor Link Information One of the main causes of poor links is often poor copywriting. Most screen readers allow the user to quickly see a list of links on a page (in the most-used commercial screen reader, JAWS, the keyboard shortcut is Ins + F7; in the free NVDA screen reader , the same keyboard shortcut brings up an Elements List that lists page links, headings, and landmarks). However, if every link has text saying “Click here” or “Read more”, with nothing else to distinguish them, this is useless. The easiest way to solve this is simply to write unique link text, but if that isn’t possible, you can over-ride the link text for assistive technology by using a unique aria-label attribute on each link. Here’s a good example from the Joomla website The visible link text is simply “read more”, but Joomla uses aria-label attributes to make each unique to assistive technology: /*aria-label="Read more: Joomla Group 2 - President election results">Read more
aria-label="Read more: Forum for the Future: Re-Engage & Re-Ignite Stream">Read more Because of the aria-label text will be used instead of the link text by assistive technologies, W3C recommends starting the text used in aria-label with the text used within the link as “this will allow consistent communication between users”. Note: It’s not recommended to add explanatory text on links using the title attribute: /* Read more> Don’t do this. The title isn’t exposed to most screen readers (developers used to stuff it with keywords for “SEO” purposes, so screen reader vendors disabled it by default), and browsers present title attributes as ‘tooltips’ which are only available to mouse users on hover. Links Should Look Like Links By default, browsers underline links. It’s best not to change this, but if you lose a fight in the car park with the designer about this, the link text must have a 3:1 contrast ratio from the surrounding non-link text and should give some ‘non-color designator” that they are a link when hovered or focussed, for example: /*a:hover, a:focus {text-decoration: underline;} The focus style causes the link to become underlined when a non-mouse user focuses on it from the keyboard, stylus, or voice input. Generally, whenever something on a page has a hover style, it should also be given a focus style. The ‘non-color designator’ (in our case, an underline) ensures that visitors with low vision or color blindness will see the change on hover or focus. (Screen readers automatically announce “Link” before link text.) Tell People If Link Opens a New Tab/ Page It can be confusing to a visitor if activating a link opens a new tab or a new window, particularly if only some links on a page do this (for example, only external links open a new tab). If you must do this, you should alert the user either in the link text, or using the aria-label method above. Tell People If Link Is to a File If a link is to a file (for example, a PDF or a video), tell the user in the link text. Don’t hide it in aria-label , as this can be useful for many sighted users (some mobiles can’t open a .docx file, for example). If it is a large file, consider alerting the user of the approximate size; they may not wish to download a large video file over 3G. You can also use the attribute, which causes the browser to open the operating system’s native file download dialogue. Putting this all together, the code will look like this: /*Annual report (PDF, 240 MB) In brief: make links identifiable, with unique link text. Warn users if a link will open a new tab or a file. 6) Another Design Error: Removing the Focus Ring We’ve mentioned :focus styles before. They are an invaluable visual indicator for those people who can’t use a mouse for whatever reason: perhaps they have RSI, or Parkinson’s or Multiple Sclerosis. However, some people consider this aesthetically displeasing when they’re using a mouse and turn it off with CSS, thereby leaving the site inaccessible to keyboard users. Enter a new standard, pioneered by Firefox, called :focus-visible . This will apply a focus ring to an element if it has been reached by a keyboard or a non-mouse pointing device but show nothing to mouse users. As it’s only supported in Firefox (at time of writing), Patrick Lauke suggests the following CSS to play nicely with all browsers: /* button:focus { /* some exciting button focus styles */ } button:focus:not(:focus-visible) { /* undo all the above focused button styles if the button has focus but the browser wouldn't normally show default focus styles */ button:focus-visible { /* some even *more* exciting button focus styles */ } In brief: make sure a keyboard user can always see where they are currently focused. 7) Form Filling Given the vital importance of forms to eCommerce sites, it’s astonishing how many inaccessible forms there are. Often this is because old browsers didn’t allow much in the way of styling form elements, so developers faked them with other HTML elements. Modern browsers allow attractive checkboxes, radio buttons custom select components and comboboxes accessible autocomplete controls , and more. Autofill Is Your Friend Allowing browsers to auto-fill forms requires visitors to do less, so they’re more likely to complete a form and sign up/buy your product. Autofill on Browsers: A Deep Dive is a great article by eBay about this (and they should know). Also, autocomplete is the only sufficient technique currently for achieving AA compliance with Success Criterion 1.3.5: Identify Input Purpose Make Form Fields Look Like Form Fields By default, browsers display form input fields as boxes. By all means, style these with margins, padding, and borders, but keep them as boxes. Many designers followed Google’s pre-2017 Material Design pattern of using a single line for the user to input text: However, Google found that the line under the old text fields was not clear to some users, often confused with a divider, and changed the design. In a usability test with 600 participants, they discovered that enclosed text fields with a box shape performed better than those with line affordance. If you are considering adopting Google’s full Material Design UI library, read Stop using Material Design text fields! to see whether it meets your needs. Label All Form Fields All form fields (text inputs, checkboxes, radio buttons, sliders, etc) need to be labeled. The best way to do this is to use an HTML
