Checklist for Web Developers

The focus of web developers, is to ensure that the basic code used for a web accessibility project functions properly. They need to become familiar with accessible code solutions, such as keyboard functionality is accessible through code and they should know when to use ARIA to convey appropriate information to assistive technology users.

 

  • Inaccessible Code

In this example, there is a Facebook icon font inside a link. However, no alternative text is provided in the code to tell assistive technology users the link will take them to Facebook.

 

<p>

<a href=”#”>

<span class=”fab fa-facebook-square fa-2x”></span>

</a>

</p>

Accessible Code

Now, alternative text has been provided for the Facebook icon font using the ARIA attribute aria-label. Screen readers will treat the icon font as an image, and the link will inherit the accessible text of the icon font.

 

<p>

<a href=”#”>

<span class=”fa fa-facebook-official fa-2x” aria-label=”Our Facebook page”></span>

</a>

</p>

 

  • Manual Testing

As web developers create code, they should also test their code so that they can catch issues early on and ensure that their code works properly. Automated testing can be extremely effective in finding accessibility issues early. Web developers should also conduct manual testing as they are building code. At a minimum, they should conduct keyboard-only testing (ensuring that functionality is available through keyboard alone) and both keyboard and screen reader testing for any custom widgets and client-side scripting that is used in the project.

 

  • Build Accessible Code Libraries

It is a good idea for organizations to build their own accessible code libraries as well as have access to other accessible code libraries. Code libraries that provide reusable, ready-to-go accessible code and widgets are an incredibly useful way to efficiently and reliably integrate accessibility into projects.

 

Checklist:

 

1 Semantics and Structure

Can structure, information, and relationships conveyed through visual presentation (in headings, lists, menus, forms, etc.) be programmatically determined?

 

2 Readability

The reading order should be tested to confirm that all content on the page is available in a logical order for assistive technologies.

 

3 Images

Do all linked, informative, and decorative <img> elements have appropriate alternative text (e.g., alt attributes)?

Do all informative background images have alternative text that can be read by assistive technologies?

 

4 Keyboard and Navigation

When interacting with a page with the keyboard is focus always visible, is it managed when necessary, and does it follow a logical order?

Can all functionality be accomplished using only the keyboard?

Do all keyboard-only (and touchscreen) interactions follow expected patterns so users know how to interact with all widgets on the page?

 

5 Tables

Are data tables marked up to convey the correct relationships between data cells and their related column or row header cells?

Do layout tables contain only <td> cells and no other structural markup such as a <th> or <caption> tag?

 

6 Form Labels

Do form controls have visible labels? Are the label and control programmatically connected?

 

7 Form Errors

The error descriptions should be programmatically associated with their form element.

If an error is noticed on form submission, screen reader users should be aware of it.

If a validation error occurs during user input or when a user moves focus, the error message should be spoken by a screen reader.

 

8 Custom Controls

Do all custom controls, scripted components and widgets provide names and roles to mimic native HTML controls and are they programmatically determinable?

For scrolling, moving, blinking, dynamic or auto-updating content, functions should be provided to stop, pause, hide, and control it.

 

9 Context Changes

Has it been confirmed that when an element receives focus, for example by tabbing to it, no major change of setting is automatically activated?

Has it been confirmed that when a person changes the setting of a user interface component, no major change of setting is automatically activated unless they have been notified earlier?

 

10 Timing

Can the time limit for completing a task be turned off, adjusted, or extended by the user — unless an exception applies?

 

 

Author: admin

Freelance Certified Web Accessibility Specialists