Front-End Developer

Front end development typically builds the parts of a product that will be interacted with by the user - specifically, the user interface. For the purpose of this resource, front end development refers to the implementation or codification of the design in functional templates for a product using technologies such as HTML, CSS and JavaScript.

Front-End Development Checkpoints – Starter List

Here is a list of checkpoints for front-end developers and engineers to get started. If these checkpoints aren't met, your code can cause significant barriers to users.

This list is taken from the full list of Front-end Development checkpoints.

For all role checkpoints, see the [Checkpoint Full List].

Case Study: How to use the Starter List

A good way to get familiar with the checkpoints is to do a short case study. Think about how you might tackle the checkpoint in your role.

Then, think of how meeting this checkpoint impacts an end user.

Checkpoint:

INP-004: All actionable elements can be reached, using only the keyboard.

Primary Role: Front-end Developer

As a front-end developer, I will code all functionality of the content, on a web page and/or within individual components and elements, to ensure it is operable through a keyboard interface only. This also allows switch control systems to operate.

Secondary Role: UX Designer

As the UX designer in support of the Front-end Developer, I will ensure to annotate my designs, wireframes and prototypes to clearly define the functionality of components on the page and the expected reading order to allow a keyboard user access to the page content.

End User persona 1: Kaseem, teenager who is deaf and blind

Kaseem is a teenager who is deaf and recently became legally blind too, which means she can see only small portions of a screen and read text when it is significantly enlarged. She uses screen magnification software to enlarge the text on websites to a suitable font size, displays text on a refreshable Braille device and a large computer screen with high resolution and high luminosity (brightness).

The viewport, or area that Kaseem sees when the screen is magnified, is very small. So the focus must be in or very close to that 'viewport' at all times. Shifting it unexpectedly to a completely different areas of the screen makes it very difficult to find and then move to that area, especially if she has no idea where the focus has landed. The focus could move to another area on the page, or to a completely new page.

End user persona 2: Alex, reporter with repetitive stress injury

Alex has worked as a reporter for more than 20 years and has developed a repetitive strain injury that makes it painful to use a mouse and to type for extended periods of time. Alex encounters problems when websites and other online content cannot be navigated by keyboard commands alone.

If when navigating the web page, if the keyboard focus shifts unexpectedly, can Alex get back to the task he was doing?

End user persona 3: Ilya, senior staff member who is blind

Ilya is blind. She is the chief accountant at an insurance company that uses web-based documents and forms over a corporate intranet and like many other blind computer users, she does not read Braille.

Ilya relies on the screen reader assistive technology to let her know where she is on the web page. Moving the focus unexpectedly breaks the context of the page and her mental map or perception of the page.

Read the full user stories

Resources

• Use the WAI Tips for Developing to get started.
• See the WAI Tutorials for menus, tables, forms and more.
• Review the WAI-ARIA Authoring Practices Guide (APG) for keyboard functionality for ARIA components.

Exercise: Role-based Decision Tree Example

Who is the primary owner of checkpoint INP-004?

Let's get started on INP-004: All actionable elements can be reached, using only the keyboard.

Using the Role-based Decision Tree, let's see how we might assign ownership.

Try it for yourself!

Try the exercise with another checkpoint from the Starter List above.