Making Theme Accessibility Ready in WordPress

Accessibility means access generally. Accessibility in web design means creating web pages that everyone can use, regardless of disability or special needs, use and benefit from everything within their environment.

According to Wikipedia:

Accessibility refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers).

In WordPress, there is a mission to make WordPress accessible to everyone including the more than one billion humans with disabilities. And regular progress shows that this mission will be achieved in near future.

After hearing so much about Accessibility in WordPress, I wanted to try it in my theme also. So I decided to make my free theme Simple Life accessible. I was new and I did not know anything about making theme accessible. After spending few hours learning about key elements under Accessibility, I started modifying my theme. Honestly speaking, it took some iterations to finally make my theme fully accessible but I learned a lot in the process and I am happy about that. I want to share some points which are important while developing accessible WordPress theme or plugin.

  • Headings: You should always use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup must not be used for presentational purposes. For example, there must be one and only one h1 tag in a page. Heading should not skip levels. h1 should be followed by h2, not h3.
  • Keyboard Navigation: Site elements like links, buttons, form fields, dropdown menus, etc should be able for navigation using keyboard. This will specifically benefit keyboard-dependent navigators or users of alternative input devices who are sighted. When any link is focused it should be visually distinctive. Tab order should be natural. Also you should not use ‘tabindex’ attribute. Tab and Shift+Tab key should work as expected.
  • Controls: If you have any feature that behave as buttons or links then you must use <button>, <input>, or <a> elements, to ensure native keyboard accessibility and interaction with screen reader. Also all controls must also have machine-readable text to indicate the nature of the control.
  • Forms: All forms in your theme of plugin must have appropriate field labels and all content within form tags need to be explicitly associated to a form control. Post-submission responses (errors or confirmations) must be perceivable. Each field inputs should be explicitly associated with <label> elements.
  • Skip Links: This is specially required for themes. Themes must include a mechanism that enables users to navigate directly to content or navigation on entering any given page. These links may be positioned off screen initially but must be available to screen reader users and must be visible on focus for sighted keyboard navigators. Skip link should be first focusable link in the page. It should be visible when keyboard focus moves to the link and this link should move focus to the main content area of the page when activated.
  • Link Text: Generally ‘read more’ links are used in themes. But there are more things those needs to be considered keeping such links. Links must avoid repetitive non-contextual text strings such as ‘read more’ and should make sense if taken out of context. Bare urls must not be used as links. Supporting text may use a screen reader class to hide text visually.
  • ARIA Landmark Roles: ARIA landmarks are attributes you can add to elements in your page to define areas like the main content or a navigation region. It provide method for screen readers to navigate to the large structural regions of a site. All content on your site must be wrapped in at least one landmark role. Any content not wrapped in a landmark role is ‘orphaned’, and may not be found by screen reader users. You can find more about ARIA landmarks and example here. Using ARIA landmarks to identify regions of a page
  • Contrasts: You must ensure that all background/foreground color contrasts for plain content text are within the level AA contrast ratio (4.5:1) specified in the Web Content Accessibility Guidelines (WCAG) 2.0 for color luminosity. Background/foreground color contrast also applies to change of state (:focus or :hover) if there is no additional indicator of :focus or :hover, such as a text decoration change. You can find some online tools to check contrasts.
  • Images: Theme or plugins may have implemented images. Decorative images must be included using CSS. Where you add images to template markup or provide a method for end users to add images, you must incorporate an appropriate alt attribute or the means for an end user to provide one. Every ‘img’ tag must have ‘alt’ attribute. If you have used any icon fonts like Font Awesome of Genericons, then you must implement ‘aria-hidden’ for such tags.
  • Media: Media resources must NOT auto start or change without user action as a default configuration. This includes resources such as audio, video, or image/content sliders and carousels.

Some useful links:

Image source: Linkedin

3 thoughts on “Making Theme Accessibility Ready in WordPress

  1. Appreciating the time and energy you put into your site and in depth information you offer.
    It’s nice to come across a blog every once in a while that isn’t
    the same unwanted rehashed material. Wonderful read!
    I’ve saved your site and I’m including your RSS feeds to my Google account.

Leave a Reply

Your email address will not be published. Required fields are marked *