If you are considering designing a site on your own this includes items for accessibility, performance, device support, interoperability, and language. Pull requests welcome!
- Minify CSS and JS, and remove unused/redundant code [#1]
- Maintain terse HTML, without over-reliance on
<div>scaffolding [#1] - Use screen reader and keyboard accessible HTML [#1]
- Compress raster images [#1]
- Optimize SVG path data [#1]
- Make sure heading levels describe a logical section/subsection structure [#1]
- Only include heading elements where they introduce sections of content
- Remove potentially insensitive or uninclusive language (use “singular they”) [#1]
- Give video content captions and transcripts
- Provide transcripts for audio content
- Make sure main body (paragraph) text is no smaller than the default (user agent) size [#1]
- Support “pinch zoom” (remove
user-scalable=noif present) - Use relative units (
em,rem, andch), especially for font metrics - Make sure styles and scripts are not render blocking [#1]
- Install a service worker and cache all applicable assets [#1]
- Use content-based, not device-specific, media queries [#1]
- Provide alternatives and/or descriptions for complex visualizations
- Include only clear, meaningful animations
- Honor requests to remove animation via the
prefers-reduced-motionmedia query - Make sure controls do not elicit unexpected or jarring behavior [#1] [#2]
- Do not include third parties that compromise user privacy [#1]
- Do not recreate supported and expected browser behaviors with bespoke scripts
- Support Windows high contrast mode (use images, not background images) [#1]
- Provide alternative text for salient images [#1]
- Apply
alt="oraria-hidden="true"to decorative images [#1] - Make sure text and background colors contrast sufficiently [#1]
- Provide
<title>s that name the site and the specific page [#1] - Provide large touch “targets” for interactive elements [#1]
- Use data tables (
<table>) for data only, not visual layout purposes - Make scrollable elements focusable for keyboard users
- Do not rely on color for differentiation of visual elements
- Use the same design patterns to solve the same problems
- Ensure keyboard focus order is logical regarding visual layout
- Lazy load large image assets
- Honour DNT (Do Not Track) header [#1]
- Translate / spell out acronyms the first time you use them
- Do not hijack standard scrolling behavior
- Move focus between dialogs and the controls that invoked them
- Give all form elements permanently visible labels
- Give grouped form elements group labels
- Place labels above form elements
- Provide status and error messages as WAI-ARIA live regions
- Provide clear, unambiguous focus styles
- Employ well-balanced, highly legible fonts (not too complex or elaborate)
- Do not use very thin font faces [#1]
- Ensure states (pressed, expanded, invalid, etc) are communicated to assistive software
- Match semantics to behavior for assistive technology users
- Provide a default language and use
lang="[ISO code]"for subsections in different languages - Make controls look like controls; give them strong perceived affordance
- Underline links — at least in body copy
- Make sure all content belongs to a landmark element (
<header>,<footer>,<nav>,<main>, etc) - Avoid pure white or pure black shades
- Mark invalid fields clearly and provide associated error messages
- Ensure content is not obscured through zooming (no fixed widths)
- Provide a
manifest.jsonfile for identifiable homescreen entries - Indicate swipe gesture support clearly, and provide simple tap-based alternatives
- Make sure data tables wider than their container can be scrolled horizontally
- Avoid time constraints where possible; provide a clear warning and option to extend where not possible
- Label and describe the same things with the same terminology
- Ensure disabled controls are not focusable
- Do not instate “infinite scroll” by default; provide buttons to load more items
- Avoid justified body text [#1]
- Provide enough spacing between lines of text (
line-height) [#1] - Ensure PDF content is accessible (include tags) [#1]
- Provide a skip link if necessary [#1]
- Avoid all-caps text [#1]
- Ensure that content is written as clearly and simply as possible [#1]
- Provide descriptive captions for figures
- Warn users of links that have unusual behaviors, like linking off-site, or loading a new tab
- Make content easier to find and improve search results with structured data [#1]
- Use textual labels to make voice activation cues obvious
- Do not mark up subheadings/straplines with separate heading elements
- Ensure primary calls to action are easy to recognize and reach
- Avoid images of text — text that cannot be translated, selected, or understood by assistive tech
- Provide a print stylesheet (single column, with interactive content hidden)
- Use well-established, therefore recognizable, icons and symbols
- Subset fonts to just the characters needed
- Instead of obstructing users with CAPTCHAs, use honeypots [#1]
- Begin long, multi-section documents with a table of contents
- Don”t make users perform actions to reveal content unless completely necessary
- If content is meant to be hidden, ensure it is properly hidden to all users
- Make sure controls within hidden content are not focusable
- Use
srcsetto tailor images to devices and reduce bandwidth costs - Do not auto focus form fields, on page load
- Break up long and complex forms into discrete sections and/or screens
- Make forms as short as possible; offer shortcuts like autocompleting the address using the postcode
- Ensure the same content is available across different devices and platforms
- Inform the user when there are important changes to the application state
- Make sure the purpose of a link is clearly described: “read more” vs. “read more about accessibility”