Visual Characteristics

Why this matters

Not every student experiences information the same way. A blind student cannot see “the red button” and has no concept of “left” versus “right” when using a screen reader that reads content sequentially. A student with a cognitive disability or low vision may struggle to identify shapes or small visual distinctions. A student using voice navigation cannot locate “the second icon in the toolbar.”

Permanent disabilities like blindness or color blindness mean some students will never perceive visual characteristics the way sighted people do. Temporary situations matter too: a student with a concussion may struggle with visual processing; someone with a broken arm may use voice control and cannot perform fine motor tasks to click small targets.

Situational factors also apply. In a bright outdoor environment, visual contrasts blur. On a small screen or with magnified text, “the bottom section” becomes meaningless when the bottom may be off-screen.

Removing reliance on visual characteristics alone is essential for ADA Title II and WCAG 2.1 AA compliance. It also creates clearer, more usable experiences for everyone by providing multiple ways to find and understand information.

What Not to Do: Using Visuals Alone

Never rely on a single visual characteristic to communicate required information. Consider all the ways students might interact with your content:

Color Alone

• Poor: “Required fields are marked in red.”
• Better: “Required fields are marked with a red asterisk (*) and the word ‘required.'”
• Why: Color-blind students won’t see red, but they’ll see the asterisk and text.

Size Alone

• Poor: “The larger text indicates headings.”
• Better: Use semantic HTML heading tags (<h1>, <h2>, etc.) in addition to sizing.
• Why: Screen readers announce heading levels. Users on small screens or with low vision see all text might be similar size; structure metadata helps them navigate.

Position Alone

• Poor: “The most important link is in the top-right corner.”
• Better: “The ‘Get Started’ button appears at the top of the page and is also linked in the main navigation menu.”
• Why: Screen readers don’t describe visual position. A student using voice navigation won’t find content based on location. Multiple pathways ensure access.

Shape Alone

• Poor: “Click the star to save your work.”
• Better: “Click the star icon labeled ‘Save’ to save your work.”
• Why: An icon without text is invisible to screen reader users. Always pair icons with descriptive text or alt text.

Orientation Alone

• Poor: “To submit, flip your device to landscape mode.”
• Better: “The submit button appears when the screen width is sufficient; rotate your device if needed.”
• Why: Some students cannot rotate devices due to motor disabilities. Provide alternative input methods (on-screen buttons, keyboard shortcuts) and avoid forcing specific orientations.

Conveying Meaning Accessibly

The solution is straightforward: provide meaning in multiple ways. Combine visual characteristics with text, labels, and structure.

Icons

• Always provide text labels or descriptive alt text for icons.
• In menus, pair icons with text: “Home (house icon)” or use tooltips on hover.
• For buttons, ensure the text label is clear: “Save” not just a floppy disk icon.

Color-Coded Information

• Supplement color with text labels: “Status: Active (green)” or use visual patterns alongside color.
• In charts, use both color and symbols or patterns.
• In dashboards, label regions or states with text.

Hierarchical Information

• Use semantic HTML heading tags for structure, not just size or color.
• Use lists (ordered, unordered, description lists) for grouped content.
• Use bold, underline, or text emphasis in addition to visual styling.

Spatial Relationships

• Describe position or grouping with text: “These related fields:” followed by a list.
• Use ARIA landmarks and HTML structure (nav, main, aside, section) to help screen readers understand layout.
• Number steps: “Step 1: Enter your name” instead of “First, click the top field.”

Sensory Characteristics in Instructions

Instructions that rely on sensory perception exclude students who don’t perceive that sense the way others do.

Visual Instructions

• Poor: “See the green button on the left sidebar.”
• Better: “Click the ‘Submit’ button in the left sidebar.”
• Even better: “Click the ‘Submit’ button” (let the DOM order and labels speak for themselves).

Auditory Instructions

• Poor: “Listen for the confirmation sound when you submit.”
• Better: “You’ll see a confirmation message saying ‘Submission received’ and receive a confirmation email.”
• Why: Deaf or hard-of-hearing students won’t hear audio cues. Provide visual and textual confirmation too.

Motor-Based Instructions

• Poor: “Swipe left to delete an item.”
• Better: “Swipe left or click the delete button to remove an item.”
• Why: Students with motor disabilities may not be able to perform swipe gestures. Provide alternative interactions (buttons, keyboard shortcuts).

Practical Examples

Example 1: A Form

Poor design:

• Required fields marked only with red color.
• Hint text only appears when hovering (not visible on mobile or to keyboard users).
• Error messages appear in red text without descriptive language.

Better design:

• Required fields are labeled “required” and marked with a red asterisk (*).
• Hint text appears below the field at all times.
• Error messages use red text AND descriptive language: “Error: Name field is required.”

Example 2: A Dashboard

Poor design:

• Status indicators are colored boxes only (red, yellow, green).
• Important metrics are only highlighted by size or position.

Better design:

• Status indicators include text: “Critical (red box)” or use icons + text.
• Important metrics appear in a dedicated “Key Metrics” section with clear labels.

Example 3: An Infographic

Poor design:

• Shows trends using only size (larger = better) or position (top = best).
• Uses color alone to distinguish categories.

Better design:

• Includes data labels with actual numbers.
• Uses color plus patterns or icons to distinguish categories.
• Provides an accompanying data table for screen reader users.

Common mistakes to avoid

• Forgetting about color-blind users: “Select a blue option” fails. Provide text labels or paired visual cues.
• Icon-only interfaces: Icons look clean but are inaccessible without labels. Always include alt text or accompanying text.
• Hover-only content: Hint text, tooltips, or important information that only appear on hover are invisible to keyboard and screen reader users. Show this information at all times or in a different, always-visible way.
• Visual hierarchy without semantic structure: Large, colored text looks like a heading but isn’t marked as one in HTML. Students relying on outline navigation or heading jumps will miss it.
• Position-based navigation: “Click the top-right corner” fails for magnified, mobile, or screen reader users. Use descriptive labels and menu navigation.
• Assuming visual positioning is obvious: “The button next to the field” is unclear. Provide explicit labels or proximity information in text.
• Animation or movement alone: A blinking indicator or moving element conveys urgency only visually. Add text, sound (with captions), or persistent visual markers.

Related DASH resources

• Use color with text labels and patterns to avoid relying on color alone
• Ensure icons and images have alt text
• Pair visual design with data tables and clear labels
• Ensure buttons and links are labeled clearly and descriptively
• Use semantic heading structure to convey hierarchy

Getting help

UGA’s Digital Accessibility Services Hub (DASH) is here to support you. Whether you need guidance on making your content accessible, help troubleshooting an issue, or training for your team, we are ready to help.

• Contact DASH at [email protected] for consultations, training, or technical assistance.

Accessibility is a shared responsibility, and every step you take makes UGA’s digital environment more inclusive.