PowerPoint Presentation

Reusable acceptance criteria and test cases for accessibilitySarah Pulis Director Accessibility ServicesTweet at me: @sarahtp

creating an inclusive digital world intopia.digital

1

Setting the sceneAccessibility remediation of select pages on a transactional portalVery little native semantic HTMLOne accessibility specialist supporting a team of 8 developers and 3 QATeam had limited knowledge of accessibility, WCAG 2.0 and assistive technologiesAggressive timelines

The QA team was required to record each test that passed/failed for each test case

Establishing your test objectivesFor each release, the product must meet WCAG 2.0 to a particular level, and work as expected with a defined list of technology combinations

How we worked with the team

Working with the teamComplete a quick review of component/page to be remediatedAnnotate screenshots with what needs to be fixedBrief the developers and the testers on expected outputTesters initially started working on acceptance criteria and test cases

5

Types of acceptance criteriaPage-level acceptance criteriaComponent-level acceptance criteria (generic or custom)

Page-level acceptance criteriaMust only be tested once on a page, such as page title or can only be tested in context of the page, such as reading order

Component-level acceptance criteriaWidgets or common design patterns that can be tested discretely, such as form inputs, show/hide content sections or modal and non-modal dialogs

Page titlePage levelHeadingsPage levelText fieldComponent levelButtonComponent levelGroup of input fieldsMultiple component levelSimple example of page-level versus component-level criteriaLanguage of pagePage levelContent orderPage level

Page-level acceptance criteriaContent order (1.3.2 - A)Focus order (2.4.3 A)Sensory characteristics (1.3.3 A) Use of colour (1.4.1 A) Contrast (1.4.3 AA) Resize text (1.4.4 AA) Headings (1.3.1 A; 2.4.6 AA) Language of page (3.1.1 A) Consistent navigation (3.2.3 AA) Consistent identification (3.2.4 AA)No keyboard trap (2.1.2 A) Timing adjustable (2.1.1 A)Seizures (2.3.1 A)Bypass blocks (2.4.1 A)Page titled (2.4.2 A)Link purpose (2.4.4 A)Multiple ways (2.4.5 A)Parsing (4.1.1 A)

Simple component-level acceptance criteriaImagesdecorative imagesmeaningful imagessimple imagecomplex imageimages of textMultimediaaudiovideoaudio-controlFormsinput and select fieldsbuttonsCAPTCHAsOn focusOn inputErrorsTables

Complex component-level acceptance criteriaGeneric complex componentsCarouselsAccordionsModal and non-modal dialogsMenusSlidersDropdownCustom complex componentsComponents that are specific to the project

Sample acceptance criteria and test cases

Acceptance criteriaAcceptance criteria are often expressed using behaviour-driven development (BDD) which uses a given-when-then template to define scenarios:Given some initial context,When an event occurs,Then ensure some outcomes.

Acceptance criteria for page titleGiven that I am on a pageWhen I read the page titleThe page title identifies the content of the page (2.4.2 Page Titled A)The title is different from other pages in the site or app, and adequately distinguishes the page from other pages (2.4.2 Page Titled A)

Test process for code inspectionExamine the source code of the HTML or XHTML document and check that a non-empty element appears in the section.Check that the page title adequately and briefly describes the content of the page.Check that the title is different from other pages on the site or app, and adequately distinguishes the page from other pages.

Test process for screen readersInputExpected result1. Navigate to a new pageThe screen reader announces the page title

But we were working on a single-page app

Acceptance criteria for checkboxes (1)Given that I am on a page with a checkbox or checkboxes When I press the TAB key to move focus to a checkboxI see that focus is on the checkbox (2.1.1 Keyboard; 2.4.7 Focus Visible)And the focus indicator does not rely solely on a colour change (1.4.1 Use of Color)When I use a screen reader AND use the keyboard to focus on a checkboxI hear that I am on a checkbox (4.1.2 Name, Role, Value)I hear a descriptive label for the checkbox (1.3.1 Info and Relationship, 3.3.2 Labels or Instructions)And I hear that the checkbox is unselected (4.1.2 Name, Role, Value)

Acceptance criteria for checkboxes (2)Given that a checkbox has focusWhen I press the Space key to toggle the checkbox stateI see that the checkbox toggles between checked and unchecked (2.1.1 Keyboard; 4.1.2 Name, Role, Value)When I use a screen reader AND I press the Space key to toggle the checkbox stateI hear that the checkbox toggles between checked and unchecked (2.1.1 Keyboard; 4.1.2 Name, Role, Value)And I MAY hear that I am on a checkbox and the descriptive label for that checkbox

Acceptance criteria for checkboxes (3)Only required when there are checkboxes that have a logical grouping and require an additional label or description for the group (see example).Given that there are checkboxes are presented as a logical group with a group labelWhen I press the TAB key to move focus to the first checkbox in the groupI hear the label for the group of checkboxes (1.3.1 Info and Relationship; 3.3.2 Labels or Instructions)

Test process for code inspectionCheck that the role of checkbox is specified using one of the two HTML role methods (native and ARIA).Check that the name of the radio button is specified using one of the name methods (label, title, aria-label, aria-labelledby).If a native HTML checkbox was used to specify the role, then use the native HTML checked state. Otherwise use the custom ARIA methods for role and state.

Test process for keyboardInputExpected results1. Use the TAB key to move focus to a checkboxFocus moves to the checkbox.You can see a clear visual indicator that shows that the checkbox has focus.The indicator does not rely on a colour change.2.Use the Space key to check/uncheck the checkboxThe checkbox changes state. (e.g. from checked to unchecked, or unchecked to checked).

Test process for NVDA/JAWSInputExpected result1. Use the TAB key to move focus to a checkboxThe screen reader announces the role of checkbox.The screen reader announces that the correct state for the checkbox (selected or unselected).The screen reader announces the associated label for the checkbox.[Optional] The screen reader announces a label for checkboxes that have a logical grouping.2.Use the Space key to check/uncheck the checkboxThe screen reader announces the checkbox is selected or unselected (depending on current state).[Optional] The screen reader announces the role of checkbox and the associated label.

You can add additional test processes for assistive technologies, such as:VoiceOver on iOS (touch)TalkBack on Android (touch)Dragon Naturally Speaking

Bringing it togetherAll page-level test cases and relevant component-level test cases were executed by the QA teamAccessibility specialist was on hand for any questions or concerns

BenefitsProvides the detailed test cases required by the QA teamProvides instructions and expected outputs for keyboard and screen reader testing (and others can be added)Acceptance criteria can also be used to define requirements for projects that embed accessibility up frontReusable across projects and by distributed teams ConcernsReusable acceptance criteria will not cover every single caseInitially requires an accessibility specialist to help create the acceptance criteria and test cases Custom test cases require accessibility knowledgeDoes not give guidance on automated testing

Lets continue the conversationSarah Pulis Director Accessibility ServicesTweet at me: @sarahtp @intopiadigital

creating an inclusive digital world intopia.digital

27