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:
- get focus when user tabs to it,
- must indicate when it is in focus,
- inform the user that it has a role of combobox
- inform the user that it has a label
- inform the user that it is or it is not expanded
- inform the user that it is possible to choose one of x items
- 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
- WAI acceptance criteria for success criteria (opens in new window) has some really good points on how to make WCAG success criteria testable.
- Design patterns in WAI-ARIA authoring practices (opens in new window) should really be studied by the team, and they are also very useful for thinking about acceptance criteria.
- United Kingdom’s government blog (opens in new window) provides some insights into how they use acceptance criteria to also maintain accessibility.
- Section 508 page has some tips on acceptance criteria as well (opens in new window).
