Acceptance criteria and accessibility

(Read 1054 times)

Defining testable conditions on multiple levels will make development and testing more effective. This is when acceptance criteria is useful.

First thing first – acceptance criteria is usually a list of testable conditions that we should define when we define a task/user story (usually a developer task). So we are actually defining all the conditions that we have to meet to be done with the task.

Acceptance criteria vs. definition of done

Acceptance criteria is very specific for the task or user story while definition of done should be common for all tasks or user stories. So we could say that definition of done is on a higher level and acceptance criteria is on a lower level.

Some thoughts on accessibility acceptance criteria

Some acceptance criteria should be a common sense for everybody involved in the process – developer should think of WCAG from first line of code and on, but it is difficult to have same level of awareness for everyone.

So it is more effective to define acceptance criteria that supports our WCAG compliance strategy on a low level and make the developers remember about all requirements on that level.

Let’s think of a custom select component that we have to develop.

Besides all the UI states we must also remember that the native select defines some common patterns that all users expect to have by default, to just name some of them;

  • we can use arrow keys to move between the items in the list (options),
  • we can use enter or space key to select an item in the list and close the list,
  • we can start typing and if item with same character is in the list it will be selected,

(These are only some patterns that I selected, but there are actually also other patterns, please check them in the ARIA practices for combobox and select page (opens in new window)).

So besides all the usual accessibility acceptance criteria – like visible focus, tab order, proper roles and labels etc. we must also think of the functionality and user experience. Users expect that our custom-made select will work just like the native select does, right.

So we can see that again – accessibility acceptance criteria spans from raw technical (WCAG) standards to user experience patterns and common practices.

Writing good accessibility oriented acceptance criteria

There is no easy answer to that and again – a lot depends on the WCAG knowledge, awareness and practice in a team. If the UI and UX designer that defines the components also provides us with all the states, then it is not so easy to forget about focus indication for example. So the design itself is dictating some accessibility acceptance criteria with no additional written rules.

At the same time – if our design is also defining interactions with keyboard – then again it is not so easy to forget about it’s development, but still opening some questions and therefore better to be defined as an acceptance criteria.

So to be able to write good accessibility acceptance criteria the team must be aware of the WCAG requirements and best practices for different native and custom elements. Then we should also think about the testing and QA parts of the story – if acceptance criteria is formulated and a part of the task, then it is easier to assess the quality as well.

Let me make a simple example on – what I think is good – accessibility acceptance criteria:

The custom select field must:

  1. get focus when user tabs to it,
  2. must indicate when it is in focus,
  3. inform the user that it has a role of combobox
  4. inform the user that it has a label
  5. inform the user that it is or it is not expanded
  6. inform the user that it is possible to choose one of x items
  7. inform the user if some option is selected

So again – here we can see that acceptance criteria is directly using the design patterns that user is expecting. It is maybe more screen-reader user oriented but that is the main user group that is normally left out when team is not doing accessibility well (enough).

At the same time we can also see that using a ever-green native semantic element would save the team a lot of time, effort and testing. So again – if possible – use native semantic elements when you can.

The acceptance criteria needs more planning with custom elements that are not used frequently and then we must make sure that element really covers all required user needs.

Formulating acceptance criteria is also based on our project management methodology, so if we are for example using Behavior-driven development (BDD), then we should use “given when then” pattern. For example:

Given that I am on a page
When I read the page title
Then the page title is unique for this page and identifies the content on the page (WCAG SC-2.4.2 Success Criteria).

Accessibility acceptance criteria should have multiple scopes

I wrote about a single component’s acceptance criteria, but we should be aware that acceptance criteria should be defined on all levels, not just on component but also on container, template and other potential levels.

So I think we can split them into following:

  • Page level acceptance criteria (for example valid HTML, title, language etc.),
  • Container level acceptance criteria (for example section description, heading levels etc.),
  • Component level acceptance criteria (for example select combobox mentioned above)

I will only scratch the surface here, but as demonstrated in the list above we have to think of different levels for our acceptance criteria and some WCAG success criteria is more suitable for higher level and some not.

For example page title is absolutely on the page level and not on the component level and focus other way around.

Some resources on accessibility acceptance criteria

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as Agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work.

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: