Summary of "Dreaming of Accessible Development - Hector Osborne Rodriguez (A11yTalks - Mar 2026)"

High-level summary

Hector Osborne Rodriguez (Senior Manager, Accenture) presented “Dreaming of Accessible Development,” describing his path into accessibility, common misconceptions, organizational barriers, and concrete practices to make web development more accessible.

Main themes: - Accessibility is an ongoing practice, not a checkbox. - It requires team-wide responsibility and leadership support. - Clear, annotated requirements early in the software lifecycle dramatically improve outcomes.

He shared annotation patterns and testable acceptance-criteria examples (accordion, search/typeahead, card) and practical advice for tools, testing, and driving organizational change.

Key ideas, concepts and lessons

What accessibility is (and is not)

• Accessibility is the practice of creating websites and web apps usable by everyone, especially people with disabilities. It’s an ongoing effort that must evolve.
• Common misconceptions:
  • “Passing automated scans = accessible.” Automated tools only cover a subset of issues.
  • “Install an accessibility overlay and you’re done.”
  • “Conforming to a standard or acronym (WCAG, ADA, Section 508, etc.) alone equals accessibility.”
  • “Accessibility is just one person’s job.” Over-reliance on a single SME creates a fragile process.

Organizational realities and barriers

• Many organizations lack formal education, career paths, or sufficiently staffed accessibility teams.
• Accessibility often depends on a small number of passionate SMEs, which leads to burnout and inconsistent outcomes.
• Job listings or resumes that state “knows accessibility” don’t guarantee adequate knowledge or supervision.
• Lack of representation and visible allies reduces organizational empathy and advocacy.

What works (strategies that help)

• Secure business support and executive sponsorship; move from reactive (fix after a lawsuit) to proactive accessibility.
• Shift left: include accessibility at the earliest stages (discovery, requirements, sales/contract stages) to avoid costly fixes later.
• Teach by doing: combine training with hands-on practice (testing, reviews, workshops, office hours).
• Document issues and knowledge (versions used, environments, steps to reproduce) to reduce repeats and help vendors fix platform issues.
• Use SLAs/contracts to require accessibility fixes or reporting from third-party vendors.

Concrete methodology / actionable checklist

General practice requirements

Teams should provide:

• Leadership commitment and sponsorship.
• An inclusive mindset across product, design, engineering, QA, marketing, and HR.
• Proactive accessibility in design and development (not only QA).
• Metrics and testing integrated into the workflow.
• Accessible communication and documentation.

How to specify accessibility in requirements / design intent (annotations)

Annotate design intent everywhere a component will be used. Include:

• Purpose, interactions, and expected behavior across input methods (mouse, keyboard, screen reader, touch).
• Component anatomy and structure (for example: accordion = heading, icon, content panel).
• Content priority and semantic hierarchy (heading order, important vs. secondary content).
• Keyboard interactions:
  • Which keys operate the component (Tab, Enter, Space, arrow keys, Esc, etc.).
  • Tab order and focus expectations.
  • Visual focus indicators and contrast requirements.
• ARIA usage and constraints:
  • When ARIA roles/attributes are required (e.g., role, aria-labelledby, aria-describedby, aria-expanded).
  • Avoid hard-coded labels in ARIA; use existing content where possible.
  • Prefer semantic HTML before adding ARIA.
• Special interaction annotations:
  • Behavior for components that change page state (tabs, modals, radio-triggered dynamic forms).
  • Expectations for new/novel interactions (for example, AI chat widgets).
• Dynamic-content annotations:
  • Design and annotate failure, warning, and success states (what should be announced and how).
  • Ensure critical alerts (e.g., weather/tornado warnings) are reliably announced to assistive tech users.
• Third-party / vendor considerations:
  • Define SLAs for fixes, report paths for incidents, and vendor accessibility commitments (which WCAG level, update cadence).

Acceptance criteria & testable examples

Use specific, testable formats (Gherkin-style examples are helpful). Example acceptance criteria:

Accordion

• When keyboard focus moves to the accordion header, it receives a visible focus outline.
• Screen reader announces the element is a button and exposes its state (expanded/collapsed).
• Activating the header toggles state via keyboard (Enter or Space) and mouse; the content panel becomes accessible when expanded.

Search / Typeahead

• Visual keyboard focus is visible on the input and controls.
• Clear/reset button is reachable and operable by keyboard.
• Typeahead list items are keyboard-traversable; each item exposes role and descriptive text as needed.

Card (clickable card with nested controls)

• Specify which areas are clickable/links and whether the image is decorative or requires alt text.
• Define heading semantics.
• Avoid nesting interactive elements improperly (no link inside a link; no button inside a link); specify correct DOM structure.

Recommended practices for developers and teams

• Prefer semantic HTML and native controls over divs and custom widgets where possible.
• Learn core HTML5/CSS fundamentals; many native elements provide accessibility behavior out-of-the-box.
• Start accessibility testing with the keyboard: ensure full operability by keyboard alone.
• Use automated scanners as part of a toolkit but don’t rely on them alone. Recommended tools:
  • Axe DevTools / axe-core
  • Microsoft Accessibility Insights
  • Wave (noting Wave can be visually noisy)
  • Be aware scanners analyze the current DOM state (closed vs. opened panels) — manual exploration is still required.
• Maintain a living design system or component library with documented accessibility requirements for each component.
• Conduct code reviews focusing on semantic markup, focus handling, ARIA usage, and correct DOM structure for interactive controls.

Culture, attitude and professional development

• Be patient and kind to yourself and others; shame and anger don’t scale.
• Keep learning — accessibility is broad and evolving.
• Build networks: join Slack groups, meetups, communities, and talk to people with disabilities and other SMEs to validate approaches.
• Advocate for visible representation and sponsorship within your organization.

Tools, resources and references mentioned

• Standards and regulations: WCAG (2.x levels A/AA/AAA), EN 301 549, Section 508, ADA.
• Accessibility tools: Axe DevTools / axe-core, Microsoft Accessibility Insights, Wave.
• Documentation resources: Mozilla Developer Network (MDN), well-documented design systems.
• Examples / inspirations: Microsoft accessibility efforts (hardware, gaming), Paralympics (visibility), illustrative media references (e.g., Netflix images used in slides).

Speakers / sources featured

• Speakers:

  • Hector Osborne Rodriguez — Senior Manager, Accenture; accessibility lead (presenter)
  • Tobias Williams — Host; Senior Software Engineer, Red Hat

• Other referenced standards, tools and organizations:

  • WCAG, EN 301 549, Section 508, ADA
  • Axe DevTools / axe-core, Microsoft Accessibility Insights, Wave
  • MDN
  • Companies/organizations: Accenture, Microsoft, Red Hat, Agile Collective, Principal Financial Group
  • Other references: Paralympics, Netflix

Category

Educational

---

Share this summary

Share on X/Twitter Share on Facebook Share on LinkedIn Share on Reddit Share on WhatsApp Share on Telegram

---

Is the summary off?

If you think the summary is inaccurate, you can reprocess it with the latest model.

Reprocess summary

Video