Skip to content
University of Georgia

 

On this page

This page covers the foundations of accessible web design. It connects directly to WCAG 2.1 AA standards and ADA Title II requirements. Whether you’re creating a course website, departmental page, or project site, these principles apply. Consider this your starting point for web accessibility – dive deeper into specific topics using the links to detailed DASH guides.

 

Why this matters

Web accessibility is foundational to UGA’s digital presence and ADA obligations. Websites are primary channels for teaching, learning, research, and administration. When websites are inaccessible, they exclude students, faculty, and staff who have disabilities and fail to meet legal requirements under the Americans with Disabilities Act (ADA) Title II and Section 508 of the Rehabilitation Act.

Inaccessible websites create barriers for people with visual impairments (who rely on screen readers), motor disabilities (who use keyboard-only navigation), hearing impairments (who need captions), cognitive disabilities (who benefit from clear structure), and many others. These barriers are not inevitable – they result from design choices. Accessible web design is not a specialized skill; anyone can learn the principles and apply them.

Accessible sites benefit everyone. Clear structure helps all users navigate. Good color contrast aids readability in sunlight or on small screens. Keyboard accessibility serves people with motor disabilities and power users who prefer keyboards. Captions help language learners and people in noisy environments. Simplified language serves people with cognitive disabilities, low literacy, and non-native speakers. Building accessibility into websites from the start is more efficient and effective than retrofitting it later.

 

 

Page structure and headings

A clear, logical page structure using headings helps all users understand your content. Screen reader users rely on headings for navigation.

Heading hierarchy:

  • Every page should have one H1 (main heading). Usually this is the page title.
  • Use H2, H3, and H4 in order. Don’t skip levels (e.g., don’t jump from H1 to H3).
  • Headings show the content structure. A person scanning headings alone should understand your page’s organization.
  • Use headings to organize content, not for styling. If something looks like a heading but isn’t semantic (in a heading tag), you’re doing it wrong.

Good heading examples:

  • H1: Course Materials
  • H2: Textbooks
  • H3: Required readings
  • H3: Supplementary materials
  • H2: Lab resources

Testing heading structure: Use the HeadingsMap browser extension to see all headings on your page. You should see a logical outline.

Learn more about headings and page structure.

 

 

Links should be easy to identify and descriptive so users know where they’ll go.

Descriptive link text:

  • Link text should make sense on its own. Bad: “Click here.” Good: “Read the course materials.”
  • Avoid repeating the same link text for different destinations (e.g., multiple “Learn more” links to different pages).
  • Don’t use URLs as link text. Bad: “For more info, visit https://example.com.” Good: “Visit the course resources page.”
  • Keep link text concise but descriptive. Good balance: “Contact the Writing Center for feedback on your paper.”

Link styling:

  • Links should be visually distinct from regular text, not just by color. Use underline, border, or icon in addition to color.
  • Visited links should also be visually distinct from unvisited links.
  • Links must have sufficient color contrast. Use a contrast checker to verify.

Navigation structure:

  • Main navigation should be consistent across all pages (same menus, same order).
  • Navigation should be keyboard accessible. Test by tabbing through navigation menus.
  • Consider using breadcrumb trails (Home > Course Materials > Reading List) to show where users are in your site structure.
  • Provide a site map or search function to help users find content.

Learn more about accessible links and buttons.

Learn more about website navigation.

Back to top

 

 

Images and media

Images need text alternatives so people who can’t see them (including search engines) understand what they show.

Alt text for images:

  • Every image needs alt text that describes what the image shows. Alt text is read aloud by screen readers.
  • Write alt text as you would describe the image to someone who can’t see it. Be concise but descriptive.
  • For decorative images (that don’t convey important information), mark alt text as empty (but don’t delete the alt text field).
  • For complex images like charts or diagrams, alt text alone isn’t enough. Provide a longer description or table below the image.

Alt text examples:

  • BAD: “Image 1” or “photo”
  • GOOD: “Student studying in the library with textbooks open on a table”
  • BAD (for a decorative icon): any alt text
  • GOOD (for decorative icon): empty alt text
  • BAD (for a chart): “Chart showing data”
  • GOOD (for a chart): “Chart showing data” + visible data table below or linked table describing the data

Multimedia (video and audio):

  • Videos must have captions (for people who are deaf or hard of hearing) and transcripts (for accessibility and searchability).
  • Audio content must have transcripts.
  • Videos with important visual information should have audio description (narration describing what’s happening on screen).
  • Video players must be keyboard accessible and have controls (play, pause, volume) accessible to all users.

Learn more about image alt text.

Learn more about accessible videos.

Learn more about captions.

 

 

Forms and interactive elements

Forms need clear labels and instructions so all users can complete them successfully.

Form fields and labels:

  • Every form field needs a visible label. Don’t put instructions inside the field (placeholder text).
  • Labels should be associated with their fields so screen readers announce them together.
  • If a field is required, clearly mark it as required (with an asterisk and text explanation, not just color).
  • Group related fields clearly (e.g., address fields together).

Instructions and error messages:

  • Provide clear instructions for the form as a whole and for specific fields if needed.
  • Error messages should be clear and specific. Bad: “Error.” Good: “Email address is invalid. Please enter a valid email ([email protected]).”
  • Highlight error fields, but don’t rely on color alone. Use text or icons too.
  • Make it easy to identify and correct errors.

Interactive elements (buttons, dropdowns, etc.):

  • All interactive elements must be keyboard accessible (Tab, Enter, arrow keys).
  • Buttons should look like buttons. Don’t create buttons from links or generic elements.
  • Dropdown menus and autocomplete fields need proper ARIA labels so screen readers understand them.
  • Focus should be visible when navigating with keyboard.

Learn more about accessible form design.

 

 

Color and visual design

Visual design must be accessible to people with low vision and color blindness.

Color contrast:

  • Text must have at least 4.5:1 contrast ratio with its background (WCAG AA standard). This means very dark text on white, or white text on very dark background.
  • Graphics and UI elements need at least 3:1 contrast ratio.
  • Use a contrast checker to verify. Many are free (see Color Contrast).
  • Don’t rely on color alone to convey information. Use text labels, icons, or patterns too.

Visual design for readability:

  • Use sans-serif fonts for body text (Arial, Verdana, etc.).
  • Use at least 12px font size for body text. 14px or 16px is better.
  • Allow adequate line height and spacing between paragraphs and sections.
  • Avoid very long lines of text (max 80 characters per line is good).
  • Use left-aligned text, not centered or justified, for better readability.
  • Avoid blinking or flashing content (more than 3 times per second is a seizure risk).

Mobile responsiveness:

  • Your website must be fully accessible and functional on mobile devices (phones and tablets).
  • Test your site on mobile devices, not just on desktop.
  • Make sure touch targets (buttons, links) are large enough (at least 48×48 pixels).
  • Text should be readable without horizontal scrolling.

Learn more about color contrast.

Learn more about readable font sizes and spacing.

Learn more about mobile accessibility.

Back to top

 

 

Keyboard accessibility

Not all users can use a mouse or trackpad. Your website must be fully navigable with keyboard alone.

Keyboard navigation:

  • Tab key: Move forward through links, buttons, and form fields.
  • Shift + Tab: Move backward.
  • Enter: Activate links and buttons, submit forms.
  • Arrow keys: Navigate within form elements (radio buttons, dropdowns, etc.).

Testing keyboard accessibility:

  • Unplug your mouse or don’t use it for a while.
  • Navigate through your website using only Tab, Shift+Tab, Enter, and arrow keys.
  • Can you reach every interactive element? Is focus visible? Can you activate everything?
  • If something doesn’t work with keyboard, it needs to be fixed.

Focus indicators:

  • When navigating with keyboard, there should be a visible focus indicator (usually a box or highlight) showing which element is active.
  • Never remove focus indicators with CSS. Users with low vision and keyboard users depend on them.
  • Focus order should be logical (left to right, top to bottom).

Skip links:

  • Long websites benefit from “Skip to main content” links that let users skip repetitive navigation.
  • This is especially useful for keyboard and screen reader users.

Learn more about keyboard accessibility.

Learn more about visible focus indicators.

 

 

WCAG 2.1 AA criteria for web accessibility

Web accessibility aligns with Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, which is the standard for ADA compliance. Key criteria include:

 

 

Beyond automated tools

Automated testing tools catch many issues, but they’re not enough. Real accessibility requires manual testing and user input.

What automated tools miss:

  • Confusing or unclear instructions and error messages.
  • Illogical tab order or focus management.
  • Content that’s technically accessible but hard to understand.
  • Missing context or relationships between elements.
  • Audio description and caption quality.

Manual testing methods:

  • Keyboard testing: Navigate with keyboard only. Does everything work?
  • Screen reader testing: Use a screen reader like NVDA (free). Does the content make sense when read aloud?
  • Zoom testing: Zoom your browser to 200%. Does content still work and display properly?
  • Color blindness simulation: Use a tool to simulate different types of color vision. Can you still understand information conveyed by color?
  • Readability testing: Does your content use simple language? Would a non-expert understand it?

User testing with people with disabilities:

  • The best testing is real-world testing with actual users who have disabilities.
  • If possible, recruit people with disabilities to test your site. Offer them compensation for their time.
  • Ask them not just “Can you use this?” but “What was confusing? What was helpful?”
  • Use their feedback to improve your site.

Learn more about testing tools.

 

 

Common mistakes to avoid

  • Relying only on automated scanners: Automated tools are helpful for catching obvious issues but miss many accessibility problems. They can only check code, not user experience. Never rely on automated testing alone.
  • Ignoring keyboard testing: Many developers skip keyboard testing because they can use a mouse. Test your site using only the keyboard – press Tab to navigate, Enter to activate buttons. If you can’t use the keyboard, neither can people with motor disabilities.
  • Assuming the CMS handles accessibility: While UGA’s CMS is built to support accessibility, it only helps if you use it correctly. A misconfigured page in an accessible CMS is still inaccessible. Always check your specific pages.
  • Treating accessibility as a final step rather than throughout design: If you design without accessibility in mind and try to retrofit it later, you’ll end up with band-aid fixes that don’t work well. Build accessibility into your design decisions from the start.
  • Not testing with real assistive technology: Many people assume their site works with screen readers based on automated checks. Test with actual screen readers like NVDA or JAWS. Assistive technology can behave unexpectedly, especially with custom components.
  • Forgetting about people using keyboard-and-screen-reader combinations: Some people navigate with both keyboard and screen reader. Make sure your site works with this combination, not just with one or the other.

Back to top

 

 

 

 

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.

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

Back to top

Learn More About Digital Accessibility

Learn about the new federal rules regarding web accessibility from the U.S. Department of Justice and web content accessibility guidelines.

DOJ Web Accessibility Rule WCAG 2.1 Guidelines