a11y Roles — Developer, Designer, and Content Responsibilities

In this tutorial, you will learn about a11y roles. We cover key concepts, practical examples, and best practices to help you master this topic.

Accessibility roles for developers include semantic HTML and ARIA implementation, for designers include color contrast validation and focus state design, and for content creators include alt text, plain language, and descriptive link text.

What You'll Learn

You will learn the specific accessibility responsibilities for developers, designers, and content creators with practical examples for each role.

Why It Matters

Each role contributes differently to accessibility. Knowing your specific responsibilities helps you focus your learning and effort on what matters most for your role.

Real-World Use

At DodaTech, each role has an accessibility checklist. Developers check keyboard support and ARIA. Designers check contrast and focus states. Content writers check alt text and reading level. The checklist is reviewed before every release.

flowchart TD
  A[a11y Roles] --> B[Developers]
  A --> C[Designers]
  A --> D[Content Creators]
  B --> E[Semantic HTML]
  B --> F[ARIA roles and states]
  B --> G[Keyboard navigation]
  B --> H[Form labels and validation]
  C --> I[Color contrast WCAG AA]
  C --> J[Focus state design]
  C --> K[Responsive zoom layout]
  C --> L[Touch targets 44px]
  D --> M[Descriptive alt text]
  D --> N[Plain language]
  D --> O[Descriptive link text]
  D --> P[Clear error messages]

Developer Responsibilities

Semantic HTML

Use the correct HTML element for each purpose. Use nav for navigation, main for primary content, button for actions, and a for links. Semantic HTML provides built-in accessibility that ARIA cannot fully replicate.

ARIA Implementation

Add ARIA attributes only when native HTML semantics are insufficient. Custom widgets like tab panels, tree views, and modals require ARIA roles, states, and properties.

Keyboard Navigation

Every interactive element must be keyboard accessible. Test with Tab, Enter, Space, arrow keys, and Escape. Manage focus for dynamic content.

Form Accessibility

Associate labels with inputs using the for attribute. Provide clear error messages linked with aria-describedby.

<!-- Developer accessibility example -->
<form>
  <label for="username">Username</label>
  <input
    type="text"
    id="username"
    name="username"
    autocomplete="username"
    aria-describedby="username-hint"
    required
  >
  <p id="username-hint">Must be at least 3 characters</p>
  <button type="submit">Create account</button>
</form>

Expected behavior: Screen reader announces the label, input, and hint text together. The required attribute triggers browser validation and screen reader notification.

Designer Responsibilities

Color Contrast

Every text and background color combination must meet WCAG AA contrast ratios: 4.5:1 for normal text, 3:1 for large text. Validate colors during design, not after development.

Focus States

Every interactive element must have a visible focus indicator. Design the focus state in Figma, not just in CSS. The focus indicator must be at least 2px thick with 3:1 contrast against the unfocused state.

Zoom-Friendly Layouts

Designs must work at 200 percent to 400 percent zoom without horizontal scrolling, overlapping elements, or lost content.

/* Designer-specified accessible design tokens */
:root {
  --color-primary: #005fcc;
  --color-text: #1a1a1a;
  --color-text-secondary: #5a5a5a;
  --color-error: #d32f2f;
  --focus-ring: 2px solid #005fcc;
  --focus-offset: 2px;
  --touch-target-min: 44px;
}

Content Creator Responsibilities

Alt Text

Write descriptive alt text for informative images. Use empty alt for decorative images. Describe the content and function of the image, not just what it looks like.

Plain Language

Write at or below a lower secondary education reading level. Use short sentences, active voice, and common words. Define technical terms.

Descriptive Links

Link text must describe the destination. Do not use click here or read more.

<!-- Content creator accessibility example -->
<!-- Bad: nondescriptive link -->
<p>Our new security features are <a href="/security">here</a>.</p>

<!-- Good: descriptive link -->
<p>Learn about <a href="/security">Durga Antivirus Pro security features</a>.</p>

<!-- Bad: missing alt text -->
<img src="chart.png">

<!-- Good: descriptive alt text -->
<img src="chart.png" alt="Line chart showing 40 percent reduction in detected threats from January to June 2026">

Common Mistakes

1. Developers Using ARIA Instead of HTML

Using div role button instead of button adds unnecessary complexity. Native HTML is more reliable than ARIA.

2. Designers Not Designing Focus States

If the focus state is not in the design file, developers must guess. Guessing leads to inconsistent or missing focus indicators.

3. Content Writers Leaving Alt Text Empty on Informative Images

Decorative images should have empty alt. Informative images need descriptive alt. Confusing the two creates accessibility barriers.

4. Developers Forgetting ARIA on Dynamic Content

Content that appears or changes after page load needs aria-live or role alert to announce changes to screen readers.

5. Designers Using Color Alone

Error states shown only in red are invisible to color blind users. Add icons or text labels.

6. Content Writers Using Click Here

Screen reader users navigate by links. Click Here tells them nothing about where the link goes.

7. Any Role Assuming Accessibility Is Someone Else's Job

Accessibility is a shared responsibility. Every role must understand their part.

Practice Questions

1. What is the developer's primary accessibility responsibility?

Using semantic HTML, implementing keyboard navigation, adding ARIA appropriately, and ensuring form accessibility.

2. What is the designer's primary accessibility responsibility?

Ensuring color contrast meets WCAG AA, designing visible focus states, creating zoom-friendly layouts, and specifying 44px minimum touch targets.

3. What is the content creator's primary accessibility responsibility?

Writing descriptive alt text, using plain language, creating descriptive link text, and writing clear error messages.

4. Why should designers specify focus states in design files?

Without a designed focus state, developers must guess the appearance. This leads to inconsistent focus indicators that may not meet WCAG requirements.

5. Challenge: For your current role (developer, designer, or content), identify three accessibility improvements you can make in your next project.

FAQ

Mini Project

Create a role-specific accessibility checklist for your job. Include 5 to 10 concrete actions you will take on your next project. Share it with your team.

What's Next

Explore a11y Ethics and the moral imperative of digital inclusion. Then complete the Overview Project to apply everything you have learned.