This is where accessibility moves from “reading” to “doing.” Whether a student is submitting a quiz in Canvas, filling out a Slate form, or clicking a button in WordPress, the interaction must be clear to everyone.
The “Why”
- Functional Clarity: A screen reader user needs to know exactly what a button does before they click it. A button that just says “Go” provides no context; a button that says “Submit Application” is clear.
- Input Awareness: When a user tabs into a form field, they need to know what information is required (e.g., “First Name” vs. “Email”). If the label isn’t technically “linked” to the box, the screen reader will just say “Edit text, blank,” leaving the user guessing.
- Error Prevention: Accessible forms provide clear, text-based error messages. If a field turns red but doesn’t say “Invalid Email Address,” a color-blind or blind user won’t know why their submission failed.
Examples: Before vs. After
The “Floating Label” Problem
- Bad: You type the word “Name:” as regular text and place a text box next to it.
- The Result: Visually, it looks fine. Technically, the box is “unlabeled.” A screen reader user won’t know what to type in that specific box.
- Good: Use the Form Tool to create a Label that is programmatically associated with the input field.
- The Difference: When the user tabs to the box, the screen reader automatically announces, “Name, edit text.”
The “Icon-Only” Button Problem
- Bad: A button that is just an image of a floppy disk with no text.
- Good: A button that has the floppy disk icon and the hidden (or visible) text “Save Document.”
- The Difference: The “Good” version ensures that users who don’t recognize the icon鈥攐r can’t see it鈥攕till know the button’s function.
How-To: Strategies for Success
- Use Clear Labels: Every form field (text boxes, checkboxes, radio buttons) must have a visible, clear label. Avoid using “Placeholder text” (the gray text inside the box) as a replacement for a label, as it disappears once the user starts typing.
- Group Related Items: If you have a group of related questions (like a list of meal preferences), use a “Fieldset” or “Group” header so the user understands the context of the choices.
- Provide Instructions Upfront: If a form has specific requirements (like “Passwords must be 8 characters”), state this at the top of the form, not just after they make a mistake.
- Make Buttons Look Like Buttons: Don’t turn a random link into a button or vice versa. Use standard button shapes and colors so they are easily identifiable as interactive.
- Ensure Large Touch Targets: For mobile users, buttons should be large enough to tap easily without accidentally hitting a nearby link.
- Don’t Use Timers: Avoid forms that “time out” unless absolutely necessary for security (like a bank login). If you must use a timer, give the user an easy way to request more time.
Apply This to Your Work
Ready to build interactive content? See the specific technical steps for the platforms we use at HCU: