Why, What, and How?
Why learn accessibility as a developer?
Simply put, it’s the right thing to do. Leaving people out of the conversation, not giving people the entire picture or the entire story is not only exclusionary, in certain situations it can be very dangerous. As a developer it is part of your job to create products with integrity.
And besides all that, if you still need another reason, Google’s Performance Tests test for accessibility and if you build for accessibility the right way your client’s SEO scores will improve.
What do I need to learn?
You need to learn about different disabilities and how users interact with websites in general. If you’re building a User Interface, you really need to take into consideration the different kind of challenges people face using assistive technology or not.
Then you need to learn about assistive technologies and how they are used to interact with different browsers and devices.
This is just the beginning, and I’m already feeling overwhelmed. Luckily, a lot of work has already been done for you. You can make your web pages instantly improved and more accessible just by learning what’s in this post. Believe it or not, a lot of developers out there skip this information or implement it completely wrong.
How do I begin?
Well whether you’re a beginner or experienced dev, you’re in the right place. This post is chock full of high quality resources to take a deeper dive into, once you get the basics down.
How WordPress is becoming more Accessible
WordPress offers a great deal of Accessibility resources and also maintains standards for WordPress Themes claiming to be accessible. Accessibility Theme Developers are required to meet a set of standards to be able to claim that their theme is accessible.
The WordPress Accessibility Best Practices Handbook, is a free resource that will help developers build with accessibility in mind.
Many WordPress Developers who are passionate about this subject have come together to form the Make WordPress Accessible Team.
This team gets together and works out bugs and issues related to accessibility in WordPress Core, as well as reviewing Themes that claim to meet accessibility standards.
All Web Developers should know these basics:
Building a site or product with accessibility in mind is a great start, but where to actually start can really be confusing. Accessibility design is so in depth that trying to begin to learn it can feel really overwhelming for newer coders and experienced alike.
This How To, walks you through the basics and should give you a good foundation on how to begin building with accessibility in mind so that once you get used to this, you can delve into the deeper territories for including more and more users into being able to use your product.
Learn a little bit about creating content for accessibility
The W3C.org page for Writing for accessibility is a great place to begin. Essentially, no matter how accessible your product is, there aren't currently many full proof ways to ensure content creators are making their content accessible. It's good to know what they need to do to be accessible so you can know the basis of what you are designing for.
In general content creators need to use descriptive alt text in images, use informative and unique labeling for pages, navigation and links, use headings to convey meaning and structure, and more.
Learn the tools you can test with
- A11y Color Contrast Tester - Testing for contrast is one of the simplest tests you can do and it will help folks with all different types of visual impairments to be able to see and experience the content on your site,
- Google Lighthouse Auditor - The lighthouse auditor can provide a lot of helpful information about the accessibility features of your site as a designer and a developer. This tester is great for catching issues with CSS, and links that might create an unpleasant experience for different users.
- WAVE Chrome Extension - This browser extension gives you a high level view of your page structure, color contrast, errors, alt text and aria labels.
Learn semantic HTML Landmark roles
A role is an HTML attribute you can add to your HTML that helps accessibility tools and devices to navigate a web page.
To use a role, simply add this attribute to your HTML element:
Then insert the appropriate role type according to these brief definitions.
For example a Header tag, as a direct child of the body tag, would look something like this:
Landmark Role Definitions
Banner - A banner usually spans the width of the page and included site specific information like site title, logo, etc. A banner is at the top of the DOM (Document Object Model) structure, and the top of the page.
Complementary - Has supporting information to the main content, meant to 'compliment' the main content area. Has a similar level within the DOM hierarchy.
Contentinfo - Meant for site specific common information that is shared across all pages of the site. This is most commonly used for the footer HTML5 tag.
Form - The form landmark is meant to denote any non-search form on the page and should include an aria-label or a title, (like; aria-label="this form is for you to provide contact information for us", or title="this is a contact form"), to help users understand the purpose of the form.
Main - Identifies the main content of the page.
Navigation - Helps the user identify a list of links to use to navigate the page or the site. If a page has more than one navigation landmark, each should have a unique label to help the user understand where the navigation links are intended to take them.
Region - A region landmark is a section on the page which helps the user navigate the page or section. When more than one region is on a page you must use a unique aria-label for each to explain their purpose.
Search - A search landmark is meant to specify search forms and sections that contain search forms for users to be able to search the site easily.
Build with semantic HTML Landmarks
Below is a quick reference guide for the HTML landmarks and their default roles when used in a generic way. Tags such as the header and footer tags, when placed within another container other than the body tag, would have different roles and would need to use different aria landmarks. Check out the WAI-ARIA Authoring practices page for more.
footer - contentinfo
article - region
main - main
nav - navigation
section - region
Get the basic HTML template here:
<body> <header role="banner"> <nav role="navigation"></nav> <div role="search"> <form> <h3>This is a search form</h3> <label for="search form">Search</label> <input type="text" /> <button type="submit">Search</button> </form> </div> </header> <main role="main"></main> <aside role="complementary"></aside> <footer role="contentinfo"></footer> </body>