Accessibility Checklist
Published: | No Comments
Reading Time: 3 minutesThis accessibility checklist was created to accompany my presentation entitled ‘How to Build an Accessible WordPress Theme’. The presentation was created for WordCamp London 2019 – held on 5th – 7th April 2019.
I’ve created a write-up of key points from the presentation.
The main checklist is split into the following sections: Design, Build, and Plugins. But there is also a list of points that could be used as guidance for content authors and editors who will be maintaining a site’s content after the theme has been implemented.
Although this accessibility checklist was created with WordPress themes in mind, it could form a useful checklist for any site built on any content management system (CMS) platform.
Please comment below if you have any questions, or need clarification on any of the points. I’ll be updating the checklist from time to time so why not subscribe to notifications or follow @coolfields on Twitter to make sure you don’t miss out.
I’ll also be blogging about some of the areas covered in my presentation.
Design
- Colour contrast:
- Check that background/foreground colour contrasts meet necessary threshold.
- But avoid black on white for large blocks of text.
- Borders of input fields need to be obvious.
- Avoid text placed directly on top of images.
- Avoid using just colour to indicate meaning – use text as well.
- Avoid fully-justified text – favour left aligned for LTR languages.
- Make links and buttons look ‘clickable’ – use underlines for links, borders for buttons.
- Pair icons with text, unless the icons are very recognisable.
- Specify focus colours/styles as well as hover colours/styles – for navigation links, and links in content/sidebar. Focus styles should be at least as obvious as hover styles.
- Make room in your forms for labels – don’t just rely on placeholders.
Build
- Specify default language of the page.
- Always use semantic HTML elements – buttons, links, etc.
- Where that’s not possible ensure that alternatives identify and behave as native controls.
- Heading strategy and hierarchy for different templates and widget areas:
- One top level heading – at top of main content.
- Sensible heading hierarchy in widget areas.
- Consider screen reader text headings before navigation, widget areas, etc.
- Set up landmarks correctly:
- Only one main landmark.
- All content is contained within at least one landmark.
- Label multiple navigation areas/regions with aria-label.
- Don’t overuse landmarks in widget areas.
- Links:
- Ensure that blog links etc contain sufficient context – ‘read more’, ‘click here’, etc is not enough.
- Provide a skip link that points at <main> as first link on page.
- If links (or buttons) contain just icons (eg Social media) ensure accessible text is also present.
- Avoid redundant links – ie where image that is a link is adjacent to a text link to same desitination.
- Links which open new windows/tabs/panels warn users.
- Implement alternate text strategy for featured images in blog index page and individual posts.
- Ensure that template images (logos etc) have appropriate alternate text – especially if they are links.
- Keyboard operability:
- Is keyboard focus always obviously visible?
- Does the tab order make sense?
- Can every actionable object get keyboard focus – including in mobile/responsive views?
- Can every actionable object be operated by appropriate keystrokes?
- Does the dropdown menu work with a keyboard – even in responsive views?
- When building forms – search, comments, contact, etc:
- Ensure every input has programmatically linked label.
- Placeholders only is not acceptable.
- Ensure that all form error messages are linked to input fields.
- Define font sizes in em and rem – not px.
- Ensure users can zoom without getting horizontal scrollbars.
- Ensure users can resize text without text truncation and clashing.
- Define responsive breakpoints in em units.
- Check you’re not blocking zooming on mobiles.
- Don’t use title attributes.
- Don’t use positive tabindex values.
- Don’t use accesskey attributes.
Plugins
- Do any plugins used affect the markup sent to the user’s browser? If so, check output for added accessibility gotchas.
- Check output from Gutenberg blocks – especially those from plugins that provide accordions, tab panels, etc.
Checklist for content authors/editors
- Headings:
- Use headings to split up page into sections.
- Keep heading hierarchy sensible.
- Links:
- Ensure link text describes where the link goes to – avoid ‘click here’ etc.
- Where possible avoid links that open new window.
- Images:
- If image is a link to somewhere else, set the alt text to the link destination.
- If not a link, use the alt text to describe succinctly what the image shows or what it represents.
- Lists of things:
- Where you are listing things, use the bulleted list option, or for a step-by-step list of instructions (or whatever) use the numbered list option.
Please let me know in the Comments section below, what you found useful about this checklist, and also anything that you though wasn’t useful.
Accessible themes from WordPress.org
If you’re not into building your own accessible WordPress theme, there are some accessibility-ready themes available from the WordPress theme repository. See also my blog post How to Find an Accessible WordPress Theme.
Other posts on building accessible WordPress themes
- Building Accessible WordPress Themes – Featured Images Apr 28th, 2019
- How to Build an Accessible WordPress Theme Apr 28th, 2019
- How to Find an Accessible WordPress Theme Jan 15th, 2016
Share this page (Links open new windows/tabs)
There are no comments yet - would you like to leave one?
Like to leave a comment?
Please note: All comments are moderated before they will appear on this site.
Previous post: Street Accessibility for the Blind in Vienna (Video)
Next post: How to Build an Accessible WordPress Theme
