Skip to content
wannacode

Usability and accessibility

In short: Usability is not taste: you measure how many people finish the task, in how much time and with how many errors. Accessibility has a ready yardstick, WCAG 2.2, with criteria checked one by one. The acceptance criterion says who, which task, under what conditions and what limit.

Problem

It was easy at the demo

The shop's new checkout gets an ovation at the demo. The acceptance criterion was "Checkout is easy for the customer". Everyone in the room agreed that it is.

After the launch, a third of the customers on phones stop at the address form. The postcode field accepts only digits, and the phone keyboard shows letters. A customer with a screen reader hears "field, field, field" and does not know which is which. Nobody in the room was either of them.

The idea

Usability is measured

"Easy" is an opinion. Usability is measurable: how well specified people do a specified task under specified conditions. It is measured with three things:

  • effectiveness: did they finish the task? 8 out of 10 new customers paid without help;
  • efficiency: in how much time and with how many errors? Under 3 minutes, at most one error in the fields;
  • satisfaction: how do they feel? A score from a questionnaire, for example above 70 out of 100.

Each of the three needs a who (a new customer on a phone), which task (pays for an order with delivery) and what limit. Without them there is no test that can fail.

More precisely, if you are curious

The definition is from ISO 9241-11: the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. A popular satisfaction questionnaire is John Brooke's System Usability Scale (SUS): 10 questions, a score from 0 to 100. In ISO/IEC 25010:2023 the usability of a product is the characteristic interaction capability, with sub-characteristics such as appropriateness recognisability, learnability, operability, user error protection, user engagement, inclusivity, user assistance and self-descriptiveness.

Try it

Which one is measured?

1. Which acceptance criterion can be checked?
2. Which criterion can be checked?
3. Which criterion can be checked?

The idea

Accessibility has a ready yardstick

Accessibility is usability for everyone: for a person with a screen reader, with only a keyboard, with poor eyesight, with shaking hands. You do not have to invent a yardstick for it: there is WCAG (Web Content Accessibility Guidelines) from the W3C.

WCAG 2.2 is a list of success criteria at three levels: A (the minimum), AA (the usual target) and AAA. Every criterion is checked on its own and either passes or not:

  • normal text has a contrast of at least 4.5 : 1 against the background (AA);
  • everything works with the keyboard too (A);
  • the focus is visible (AA);
  • an error in a form is described in text, not only with colour (A);
  • a target to tap is at least 24 × 24 pixels or has enough space around it (AA, new in 2.2).

That is why the requirement "The checkout page meets WCAG 2.2, level AA" is good: it points at a list of checkable criteria. What this looks like in HTML (role, name, focus) is in the lesson Accessibility of the web interfaces course.

More precisely, if you are curious

WCAG 2.2 has been a W3C Recommendation since October 2023. In the EU the European Accessibility Act (Directive 2019/882) applies from 28 June 2025, including to e-commerce. The harmonised standard EN 301 549 points to WCAG, level AA. Automated tools (axe, Lighthouse) catch only some of the problems, most often contrast and missing labels. Whether an error message makes sense and whether the Tab order is logical is checked by a person.

Try it

Does it pass WCAG?

1. The grey text "Free delivery from 50 €" is on a white background with a contrast of 2.5 : 1.
2. The "Place order" button works with the mouse but cannot be reached with Tab.
3. An invalid email is shown only with a red border around the field.

The idea

The criterion that gets accepted

A usability requirement is written like any acceptance criterion, with a rule and examples. For example, for checkout:

Feature: Checkout with the keyboard only


  Scenario: A customer without a mouse pays for the order
    Given a customer with an order of 62.40 € who uses only the keyboard
    When they go through the checkout form with Tab, Enter and the arrow keys
    Then they pay for the order without using a mouse
    And they can see which field has focus at every step

These scenarios are not run against a reference system. A person or a tool carries them out. But they are in the same language as the functional ones and sit in the same matrix.

The usability measures (8 out of 10, under 3 minutes) are checked with a user test: five to eight people from the group the requirement is about do the task, while you watch, measure and do not help.

More precisely, if you are curious

CT-AcT v1.0, chapter 4, is about acceptance testing of non-functional requirements, with separate sections on usability and user experience, on performance and on security. The syllabus insists on the same thing: a non-functional requirement is accepted when it has a measure agreed with the business before the test. The often quoted "5 users find most problems" is Jakob Nielsen's and holds for short rounds of test, fix and test again, not for one big test.

Exercise

A usability requirement

1. Checkout. Review the designer's requirement.

Mark the words that make the requirement unverifiable, and choose what the problem is in each.

Press the words that are a problem; press again to unmark. The arrow keys move from word to word.

Test

Check yourself

1. What is usability called in ISO/IEC 25010:2023?
2. Which three things does usability measure?
3. Why is "meets WCAG 2.2, level AA" a good requirement?
4. Which testing quadrant is a usability test with real customers in?

Made by Ivo Gergov as part of Evo Tech's campaign for accessible programming education ·