Laura Wissiak, CPACC

Posted on Apr 7 • Originally published at a11ynews.substack.com

Forms Accessibility: The 8 Trusted Tester Test IDs You Need to Know

#a11y #testing #beginners #frontend

A developer’s guide to labels, context changes, error handling, and prevention based on the DHS Section 508 Trusted Tester conformance process.

You thought Keyboard Access and Focus was a big topic? Well, so was our 4th session of the DHS Section 508 Trusted Tester Study Group: Forms cover 8 Test IDs in total. Forms are where users give us their data, and where failures can block entire user journeys.

Your Forms Cheat Sheet

Labels are layered: Visual presence (5.A.), descriptive quality (5.B.), and programmatic association (5.C.)
Context changes require warning: Unexpected behavior disorients users, but warnings make changes acceptable.
Errors need both, a means of identification as well as remediation: Knowing something is wrong is only the first step, users need to know how to fix it as well.
Important submissions demand safeguards: Legal, financial, and data-modifying forms require either review mechanisms before submitting, an option to reverse submission or the page should flag errors and allow the user to correct them before final submission.

A cheat sheet for all Trusted Tester testing and evaluation steps is also in the Resources Drive folder.

The Three Pillars of Form Labels

Test IDs 5.A. - C cover form labels, splitting them into 3 smaller questions: Is the label visible? Does it make sense? Is it programmatically correct?

Note that the Trusted Tester process builds on WCAG 2.0. Due to this, I’ve included comparisons between WCAG 2.0 and 2.2 in each study group session. For all WCAG success criteria cited in relation to the topic 5 forms test IDs, neither the content nor level has changed between 2.0 and 2.2 and therefore I am only linking to 2.2 as well.

5.A.: Labels Provided (WCAG 3.3.2 Labels or Instructions)

Every form field must have a visual label or instruction that remains visible, even when the field receives focus. So no, placeholder text that disappears on focus does not count as a label. But table headers can count!

Note that this test only checks presence, not accuracy. For 5.A. we are only looking, if a label is there, not if it makes sense.

Placeholder text is not a label. If it disappears on focus, it fails 5A.

5.B.: Descriptive Labels (WCAG 2.4.6 Headings and Labels)

Labels must sufficiently describe the purpose and data requirements of each field. Users should know what data format is expected (phone number format, date format, etc.), and required field indicators must be clear. For both, clarification in text is also acceptable. Button labels must describe the function clearly, and error messages alone cannot substitute for upfront label clarity.

5.C.: Programmatic Labels (WCAG 1.3.1 Info and Relationships, WCAG 4.1.2 Name, Role, Value)
This is where we go beyond what’s visible on the screen: Form elements must have programmatic associations that assistive technologies can read. To determine this, the Trusted Tester process uses the ANDI tool: ANDI output must include all relevant instructions and cues. For general web accessibility testing purposes, you can also use the developer tools of your browser to inspect the label. Accessible names don’t need to match visual labels word for word, but they must still be adequate.

Radio buttons and checkboxes must be programmatically associated with the questions they are supposed to answer. In contrary to that, dropdown options themselves are not part of the form field description.

In the study group, our fail example was a form with multiple phone number input boxes (spaced to mimic the US phone number format of 3-3-4 digits) all reading as “phone” without distinguishing the segments for area code (3 digits), prefix (3 digits) and line number (4 digits).

Managing Context Changes

The next 2 Test IDs deal with what happens when users interact with form elements, and making sure they’re never surprised by unexpected behavior.

5.D.: Forms on Input (WCAG 3.2.2 On Input)

Changing form field values should not trigger unexpected changes of context.

To the diligent study group regular, this may sound familiar! We had a very similar test in the last session: Keyboard Access and Focus in , well, the focus part. The concept is the same, only the test ID name is different and limited to form elements instead of every keyboard accessible element on the page.

Users must be warned before a form automatically submits, new windows open, focus shifts, or the page redirects. “Unexpected” is the key word here: expected changes with warnings are acceptable.

The iconic fail example from the study group was a radio button selection for our birth year that immediately redirects to a Wikipedia page, without warning.

5.E.: Forms Change Notification (again WCAG 4.1.2 Name, Role, Value)

Users must be notified of any form-related changes on the same page.

Notification methods that pass:

ARIA live regions in which the error messages pop up.
Keyboard-accessible dialog boxes.
Focus movement to changed content with sufficient description.
Interface components that provide sufficient description of the change.

Our fail example: A ticket availability message appearing without live regions, focus movement, or any dialog notification. How are we supposed to know the show’s already sold out then?

Error Handling Excellence

The last three test IDs ensure errors are not only detected but also effectively communicated and corrected.

5.F.: Error Identification (WCAG 3.3.1 Error Identification)

Automatically detected errors must be identified and described in text, not just color or icons. The specific field in error must be identified, not just a vague “invalid input”, be precise which field is causing trouble.

Common failure: The error message consisting of only a red “X” icon or red outline without accompanying text description. Can we, as web design and development professionals, please move on already from sensory-dependent error handling? It has been plaguing UI accessibility for so long.

Note that this test does not require correction suggestions (that’s a spoiler for 5.G.)

5.G.: Error Suggestion (WCAG 3.3.3 Error Suggestion)

We have the error. Now what? When errors are detected, guidance must be provided on how to correct them. Provide suggestions on how to remedy the error, unless they would jeopardize security or purpose.

How could it jeopardize security or purpose? Great question! While most errors are outside our happy path, in certain scenarios, they can be part of the game. For example, if you are playing a guessing game

Online tests and exams are also exceptions because automated error suggestions here would go against the whole concept of testing your knowledge!

Pass Examples: Password requirements that are shown upfront, or specifying acceptable ranges for input (e.g. “input a number between 1 to 10” for customer satisfaction surveys).

Fail Example: A form asked us to input our work experience and simply answered with “Error: 5 is not acceptable” without specifying what unit or format is expected.

5.H.: Error Prevention (WCAG 3.3.4 Error Prevention)

Important transactions (we’re talking about legal, financial, and data-modifying context in particular) must allow review, confirmation, or reversal.

DEV Community