Skip to main content
SGSiteGraph
Accessibility·11 min read·

Web Accessibility Best Practices: Making Your Site Inclusive

Learn about web accessibility best practices including proper heading structure, alt text for images, color contrast, keyboard navigation, and semantic HTML.

ST

SiteGraph Team

UX Research at AnantaHQ

Web accessibility ensures that people with disabilities can perceive, understand, navigate, and interact with the web. It's not just a legal requirement in many jurisdictions — it's a fundamental aspect of good web design that benefits everyone.

An accessible website reaches a wider audience, improves SEO (many accessibility practices overlap with SEO best practices), and demonstrates a commitment to inclusivity.

Heading Structure

Proper heading structure is the backbone of accessible content. Headings create a document outline that screen reader users rely on to navigate pages. Each page should have one and only one h1 that describes the page's main topic, followed by logically nested h2, h3, etc.

Best practices:

  • Use headings to create a logical content hierarchy, not for visual styling
  • Don't skip heading levels (e.g., going from h2 to h4)
  • Keep headings descriptive and concise
  • Use only one h1 per page

Alt Text for Images

Alt text provides a textual alternative to images for screen reader users. It's also displayed when images fail to load and helps search engines understand image content.

Best practices:

  • Be descriptive but concise — describe the image's content and function
  • If an image is purely decorative, use an empty alt attribute (alt="") so screen readers ignore it
  • Don't use "image of" or "picture of" — screen readers already announce images
  • Include text that's in the image in the alt text

Color Contrast

Sufficient color contrast between text and background is essential for users with low vision or color blindness. WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.

SiteGraph checks color contrast issues as part of our accessibility analysis. Common problem areas include:

  • Light gray text on white backgrounds
  • Links that are only distinguished by color
  • Placeholder text that doesn't meet contrast requirements

Keyboard Navigation

All functionality should be operable through a keyboard interface. This includes navigation, forms, buttons, links, and any interactive elements. Users should be able to tab through content in a logical order and see a visible focus indicator on every interactive element.

Key requirements:

  • All interactive elements must be reachable via keyboard
  • Visible focus indicators (not just browser defaults)
  • Logical tab order that follows the visual layout
  • No keyboard traps — users must be able to navigate away from any component

ARIA Attributes

ARIA (Accessible Rich Internet Applications) attributes provide additional semantic information to assistive technologies when HTML alone is insufficient. Use ARIA roles, properties, and states to convey the purpose and state of custom interactive elements.

Important ARIA attributes include:

  • aria-label — Provides an accessible name for an element
  • aria-labelledby — References another element as the label
  • aria-describedby — References an element that describes this one
  • aria-expanded — Indicates whether a collapsible element is open or closed
  • aria-current — Indicates the current item in a set (e.g., current page in navigation)

Remember the first rule of ARIA: don't use ARIA if you can use a native HTML element that already has the semantics you need.

Semantic HTML

Using semantic HTML elements — <nav>, <main>, <article>, <section>, <header>, <footer>, <aside> — provides built-in accessibility benefits. These elements convey meaning to screen readers and other assistive technologies without requiring additional ARIA attributes.

Forms and Labels

Every form input must have an associated label. Use the <label> element with a for attribute matching the input's id, or wrap the input inside the label element. Error messages should be programmatically associated with their inputs using aria-describedby.

How SiteGraph Helps

SiteGraph's accessibility analysis checks for heading structure issues, missing alt text, and other common accessibility problems. While automated checks can't catch every issue (manual testing with real assistive technology is essential), they provide a valuable starting point for improving your website's accessibility.

ST

SiteGraph Team

UX Research at AnantaHQ

Frequently asked questions

Is web accessibility required by law?

In many jurisdictions, yes. The Americans with Disabilities Act (ADA) in the US, the European Accessibility Act in the EU, and similar laws in other countries require websites to be accessible. WCAG 2.1 Level AA is the most commonly referenced standard.

Does accessibility affect SEO?

Yes. Many accessibility practices overlap with SEO best practices: proper heading structure, descriptive alt text, semantic HTML, and good color contrast all benefit both accessibility and search engine rankings.

Can SiteGraph detect all accessibility issues?

No. Automated tools can detect approximately 30-40% of accessibility issues. Manual testing with screen readers, keyboard-only navigation, and real users with disabilities is essential for full compliance. SiteGraph provides a useful starting point but is not a substitute for comprehensive accessibility auditing.