{"id":75062,"date":"2026-04-16T12:18:43","date_gmt":"2026-04-16T12:18:43","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/lead-accessibility-specialist-role-blueprint-responsibilities-skills-kpis-and-career-path\/"},"modified":"2026-04-16T12:18:43","modified_gmt":"2026-04-16T12:18:43","slug":"lead-accessibility-specialist-role-blueprint-responsibilities-skills-kpis-and-career-path","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/lead-accessibility-specialist-role-blueprint-responsibilities-skills-kpis-and-career-path\/","title":{"rendered":"Lead Accessibility Specialist: Role Blueprint, Responsibilities, Skills, KPIs, and Career Path"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">1) Role Summary<\/h2>\n\n\n\n<p>The Lead Accessibility Specialist is the accountable subject-matter expert (SME) for ensuring that digital experiences\u2014web applications, mobile apps, internal tools, and customer-facing platforms\u2014are usable by people with disabilities and meet applicable accessibility standards. This role drives accessibility strategy and execution across Experience Engineering, embedding accessible design and engineering practices into product delivery so accessibility is built-in rather than audited-in later.<\/p>\n\n\n\n<p>This role exists in a software\/IT organization because accessibility is both (a) a legal\/compliance requirement in many markets and (b) a product quality and customer trust differentiator. Modern product teams ship rapidly, across multiple platforms and UI frameworks; without a dedicated lead, accessibility work becomes inconsistent, reactive, and costly to remediate.<\/p>\n\n\n\n<p>Business value created includes reduced legal and reputational risk, improved customer reach and retention, higher usability for all users, better design system quality, and fewer late-cycle defects that delay releases.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Role horizon: <strong>Current<\/strong> (well-established discipline and enterprise expectation)<\/li>\n<li>Department: <strong>Experience Engineering<\/strong> (close partnership with Design, UX Research, and Front-End Engineering)<\/li>\n<li>Typical interaction teams:<\/li>\n<li>Product Management, Design, UX Research<\/li>\n<li>Front-End and Mobile Engineering<\/li>\n<li>Quality Engineering \/ Test Automation<\/li>\n<li>Design System \/ UI Platform teams<\/li>\n<li>Legal, Risk\/Compliance, Security, Procurement (vendor tools)<\/li>\n<li>Customer Support, Sales Engineering (for enterprise accessibility questionnaires)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">2) Role Mission<\/h2>\n\n\n\n<p><strong>Core mission:<\/strong> Establish and operationalize an accessibility-by-default practice across Experience Engineering by defining standards, enabling teams with patterns and tools, auditing and guiding remediation, and verifying conformance to recognized accessibility requirements (primarily <strong>WCAG 2.1\/2.2<\/strong>, typically Level <strong>AA<\/strong>, and related regional standards where applicable).<\/p>\n\n\n\n<p><strong>Strategic importance:<\/strong> Accessibility is a product quality attribute that directly influences market access, customer trust, and regulatory posture. The Lead Accessibility Specialist ensures accessibility is treated as a first-class engineering and design requirement\u2014measured, governed, and continuously improved\u2014rather than a one-time compliance exercise.<\/p>\n\n\n\n<p><strong>Primary business outcomes expected:<\/strong>\n&#8211; Measurable improvement in accessibility conformance across priority customer journeys and core UI components.\n&#8211; Reduced production accessibility defects and lower remediation cost through earlier detection (design\/PR\/CI).\n&#8211; Operationalized governance: clear standards, repeatable testing, documented exceptions, and audit-ready evidence.\n&#8211; Increased organizational capability: teams can independently build and test accessible features, supported by patterns, training, and tooling.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3) Core Responsibilities<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Strategic responsibilities<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Accessibility strategy and roadmap:<\/strong> Define a pragmatic accessibility roadmap aligned to product priorities, regulatory expectations, and release plans (including incremental conformance targets).<\/li>\n<li><strong>Standard definition:<\/strong> Own and maintain the organization\u2019s accessibility standards and interpretation guidance (e.g., WCAG mapping, component requirements, platform specifics for web\/iOS\/Android).<\/li>\n<li><strong>Program prioritization:<\/strong> Triage and prioritize accessibility work across teams, balancing legal risk, user impact, and engineering effort.<\/li>\n<li><strong>Design system enablement:<\/strong> Influence the design system\/UI platform strategy so accessible components are the default building blocks, reducing per-team burden.<\/li>\n<li><strong>Stakeholder advisory:<\/strong> Provide credible, risk-aware guidance to executives, Product, Legal, and customer-facing teams on accessibility posture and commitments.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Operational responsibilities<\/h3>\n\n\n\n<ol class=\"wp-block-list\" start=\"6\">\n<li><strong>Accessibility intake and consultation:<\/strong> Run office hours and intake processes for design reviews, technical questions, and feature consultations.<\/li>\n<li><strong>Audit planning and execution:<\/strong> Plan and execute audits for high-impact flows; define sampling approaches, severity scoring, and evidence collection.<\/li>\n<li><strong>Backlog creation and remediation support:<\/strong> Translate findings into actionable tickets with reproducible steps and technical recommendations; support teams through remediation.<\/li>\n<li><strong>Release readiness checks:<\/strong> Establish and run accessibility readiness checkpoints for releases and major UI changes (component upgrades, navigation changes, design refreshes).<\/li>\n<li><strong>Defect prevention:<\/strong> Embed accessibility checks into Definition of Ready\/Done and standard acceptance criteria; partner with QE to prevent regressions.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Technical responsibilities<\/h3>\n\n\n\n<ol class=\"wp-block-list\" start=\"11\">\n<li><strong>Manual testing expertise:<\/strong> Perform expert testing with screen readers and assistive tech (e.g., NVDA\/JAWS\/VoiceOver\/TalkBack), keyboard-only navigation, focus management, semantics, and dynamic content behavior.<\/li>\n<li><strong>Automated testing enablement:<\/strong> Integrate automated checks into CI\/CD and local workflows using common libraries\/tools (e.g., axe-core, Accessibility Insights, Lighthouse), and define what automation can\/can\u2019t validate.<\/li>\n<li><strong>Engineering guidance:<\/strong> Provide implementation guidance for accessible patterns (ARIA usage, semantic HTML, focus trapping, modal behavior, error handling, data tables, charts, drag-and-drop alternatives).<\/li>\n<li><strong>Documentation and examples:<\/strong> Create and maintain code examples, component contracts, and \u201cgolden\u201d reference implementations for common patterns.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Cross-functional \/ stakeholder responsibilities<\/h3>\n\n\n\n<ol class=\"wp-block-list\" start=\"15\">\n<li><strong>Design partnership:<\/strong> Partner with UX and Visual Design on accessible interaction patterns, color contrast, typography, motion, and content structure.<\/li>\n<li><strong>Product partnership:<\/strong> Help Product define accessible requirements and acceptance criteria; ensure accessibility is represented in prioritization.<\/li>\n<li><strong>Vendor and third-party evaluation:<\/strong> Evaluate third-party UI components and SaaS tools for accessibility risk; advise on procurement requirements and remediation plans.<\/li>\n<li><strong>Customer and sales support:<\/strong> Provide guidance for enterprise accessibility questionnaires (e.g., VPAT\/ACR inputs) in partnership with Legal\/Compliance, and supply evidence where appropriate.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Governance, compliance, and quality responsibilities<\/h3>\n\n\n\n<ol class=\"wp-block-list\" start=\"19\">\n<li><strong>Conformance documentation:<\/strong> Contribute to or coordinate accessibility conformance reporting (e.g., VPAT\/ACR) and maintain audit trails, exceptions, and rationale.<\/li>\n<li><strong>Policy enforcement and exceptions:<\/strong> Establish governance for accessibility exceptions (time-bound waivers, risk acceptance, mitigation plans) with appropriate approvals and documentation.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Leadership responsibilities (Lead-level, typically senior IC)<\/h3>\n\n\n\n<ol class=\"wp-block-list\" start=\"21\">\n<li><strong>Capability building:<\/strong> Train and mentor designers, engineers, and QA on accessibility practices; create scalable learning paths.<\/li>\n<li><strong>Community of practice leadership:<\/strong> Facilitate an accessibility guild\/chapter, define shared standards, and align approaches across teams.<\/li>\n<li><strong>Influence without authority:<\/strong> Drive adoption through persuasion, evidence, and enabling assets; escalate only when needed, with clear risk framing.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">4) Day-to-Day Activities<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Daily activities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Review incoming questions\/tickets from teams (Slack\/Teams\/Jira) and provide quick guidance on semantics, ARIA, focus, and interaction patterns.<\/li>\n<li>Perform targeted manual testing of new UI changes (e.g., a new onboarding step, modal, complex form, or dashboard widget).<\/li>\n<li>Write or refine accessibility acceptance criteria for user stories and features in flight.<\/li>\n<li>Partner with a designer or engineer on a specific pattern (e.g., error summaries, inline validation, keyboard shortcuts, skip links).<\/li>\n<li>Update documentation snippets or component guidance as recurring issues are discovered.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Weekly activities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run <strong>accessibility office hours<\/strong> and\/or design critique participation for high-risk features.<\/li>\n<li>Conduct structured audits on a rotating basis (one or more key flows\/components), publish findings, and align with owners on remediation.<\/li>\n<li>Review pull requests for accessibility-sensitive changes (e.g., new components, navigation updates), focusing on semantics and interaction behavior.<\/li>\n<li>Coordinate with QE to keep automated accessibility checks stable and meaningful (reduce false positives, add coverage to new routes).<\/li>\n<li>Facilitate an accessibility community meeting (guild) or deliver a short enablement session.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monthly or quarterly activities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Publish an accessibility metrics\/reporting update (coverage, defect trends, remediation throughput, conformance posture).<\/li>\n<li>Refresh the accessibility roadmap based on product plans, customer escalations, and audit results.<\/li>\n<li>Run deeper audits for major releases, redesigns, or newly acquired product surfaces.<\/li>\n<li>Review and update accessibility standards and component requirements to align with evolving guidance (e.g., WCAG interpretations, platform changes).<\/li>\n<li>Conduct a retrospective on accessibility incidents or near-misses (e.g., a regression that shipped) and implement prevention changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recurring meetings or rituals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Product\/Engineering planning sessions (accessibility requirements and risk review)<\/li>\n<li>Design system backlog grooming (component-level improvements)<\/li>\n<li>Release readiness meetings (go\/no-go input for accessibility risk)<\/li>\n<li>Quarterly business reviews (QBRs) for Experience Engineering quality metrics<\/li>\n<li>Vendor\/tooling review meetings (Deque, testing tools, analytics platforms)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Incident, escalation, or emergency work (when relevant)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Respond to high-severity accessibility escalations from enterprise customers or Legal (e.g., formal complaint, procurement blockers).<\/li>\n<li>Rapid triage of an accessibility regression affecting a critical journey (login, checkout, onboarding), coordinating hotfixes and communications.<\/li>\n<li>Support urgent evidence gathering for audits or contract-related accessibility inquiries, partnering with Compliance and Support.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5) Key Deliverables<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Accessibility standards and guidelines<\/strong> (organization-specific): WCAG interpretation notes, severity definitions, testing checklists, platform-specific guidance.<\/li>\n<li><strong>Accessibility audit reports<\/strong>: scope, methodology, findings, severity, affected flows, reproduction steps, recommended fixes, evidence (screenshots, screen reader transcripts).<\/li>\n<li><strong>Remediation plans and backlogs<\/strong>: prioritized Jira epics\/stories with owners, timelines, acceptance criteria, and verification approach.<\/li>\n<li><strong>Design system accessibility requirements<\/strong>: component contracts (keyboard behavior, focus order, ARIA usage, states), and usage guidelines.<\/li>\n<li><strong>Accessible pattern library<\/strong>: documented patterns for forms, modals, menus, tables, notifications, toasts, error handling, pagination, and charts.<\/li>\n<li><strong>Automated testing enablement<\/strong>: CI integration guidelines, recommended rulesets, baseline tests, and maintenance practices.<\/li>\n<li><strong>Training assets<\/strong>: onboarding curriculum, recorded sessions, \u201chow-to\u201d guides, role-based checklists for designers\/engineers\/QE.<\/li>\n<li><strong>Governance artifacts<\/strong>: exception\/waiver process, risk acceptance templates, accessibility sign-off criteria for releases.<\/li>\n<li><strong>Conformance documentation support<\/strong>: inputs for VPAT\/ACR and customer questionnaires, with traceable evidence.<\/li>\n<li><strong>Accessibility metrics dashboard<\/strong>: coverage, issue trends, remediation throughput, component compliance, release readiness status.<\/li>\n<li><strong>Stakeholder communications<\/strong>: executive-ready summaries of posture, risks, progress, and next quarter priorities.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6) Goals, Objectives, and Milestones<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">30-day goals (first month)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build relationships with Experience Engineering leadership, Design System owners, QE leaders, Product leads, and Legal\/Compliance partners.<\/li>\n<li>Inventory current accessibility posture:<\/li>\n<li>Existing standards, tooling, audit history, known risk areas, customer escalations<\/li>\n<li>Current level of automation and manual testing practice<\/li>\n<li>Establish initial operating cadence:<\/li>\n<li>Office hours schedule<\/li>\n<li>Intake channel and triage process<\/li>\n<li>Standard audit template and severity rubric<\/li>\n<li>Deliver 1\u20132 quick-win improvements (e.g., update modal pattern guidance, fix critical navigation\/focus regression, add contrast checks to design reviews).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">60-day goals (by end of month two)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Complete baseline audits for 2\u20134 highest-traffic\/highest-risk user journeys and top 10 shared components.<\/li>\n<li>Implement or harden automated accessibility checks in CI for at least one core frontend repository (where feasible), with clear guidance on interpreting results.<\/li>\n<li>Publish role-based accessibility checklists:<\/li>\n<li>Designer checklist (contrast, motion, focus indicators, headings, error messaging)<\/li>\n<li>Engineer checklist (semantics, keyboard, focus, ARIA, announcements)<\/li>\n<li>QE checklist (assistive tech smoke tests, regression triggers)<\/li>\n<li>Align with Product\/Engineering on an initial remediation roadmap and ownership model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">90-day goals (by end of quarter one)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Establish \u201caccessibility-by-default\u201d workflow:<\/li>\n<li>Definition of Done includes accessibility criteria and verification steps<\/li>\n<li>Design review gates for high-risk features<\/li>\n<li>Release readiness criteria for critical journeys<\/li>\n<li>Demonstrate measurable progress:<\/li>\n<li>Reduce critical\/high severity issues in audited flows<\/li>\n<li>Improve design system component compliance (documented and tested)<\/li>\n<li>Stand up an accessibility guild with regular cadence and shared artifact repository.<\/li>\n<li>Produce a quarterly accessibility posture report that is understandable to executives and actionable for teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6-month milestones<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Achieve consistent testing coverage for priority flows:<\/li>\n<li>Manual screen-reader coverage for critical journeys<\/li>\n<li>Automated checks for core routes\/components with low noise<\/li>\n<li>Mature design system accessibility:<\/li>\n<li>Accessibility acceptance tests for key components<\/li>\n<li>Clear component-level contracts and usage guidelines<\/li>\n<li>Reduce time-to-remediate high-severity issues through better backlog hygiene, ownership, and verification practices.<\/li>\n<li>Formalize exception process and reporting so risk is visible and managed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12-month objectives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reach and sustain target conformance level (commonly WCAG 2.1\/2.2 AA) for defined scope (e.g., customer portal, marketing site, core mobile app surfaces).<\/li>\n<li>Demonstrably lower escaped defects:<\/li>\n<li>Fewer production accessibility incidents<\/li>\n<li>Improved customer accessibility satisfaction signals<\/li>\n<li>Establish audit readiness:<\/li>\n<li>Repeatable evidence collection<\/li>\n<li>Clear conformance reporting process (where needed)<\/li>\n<li>Create durable organizational capability:<\/li>\n<li>Engineers and designers independently deliver accessible work with minimal rework<\/li>\n<li>Accessibility is included in planning, design, implementation, and QA by default<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Long-term impact goals (beyond 12 months)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility becomes a competitive advantage:<\/li>\n<li>Faster enterprise procurement cycles<\/li>\n<li>Improved usability metrics and reduced support contacts<\/li>\n<li>A scalable accessibility operating model:<\/li>\n<li>Shared standards, federated champions, measurable compliance<\/li>\n<li>A resilient system:<\/li>\n<li>Accessibility regressions are rare, detected early, and fixed quickly<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Role success definition<\/h3>\n\n\n\n<p>The role is successful when accessibility outcomes improve measurably across the product portfolio, teams can reliably ship accessible features, and leadership has clear visibility into accessibility risk and progress.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What high performance looks like<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Proactive, not reactive: issues prevented by standards, patterns, and early feedback.<\/li>\n<li>High leverage: improvements to design systems and processes that scale across teams.<\/li>\n<li>Credible governance: clear standards, evidence, and risk management without becoming a blocker.<\/li>\n<li>Strong influence: teams seek guidance early; accessibility is considered in trade-offs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7) KPIs and Productivity Metrics<\/h2>\n\n\n\n<p>The Lead Accessibility Specialist should be measured on a balanced set of <strong>output, outcome, quality, efficiency, reliability, innovation, collaboration, satisfaction, and leadership<\/strong> metrics. Targets vary by maturity and portfolio size; examples below assume a mid-to-large software organization with multiple product teams.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Metric name<\/th>\n<th>What it measures<\/th>\n<th>Why it matters<\/th>\n<th>Example target\/benchmark<\/th>\n<th>Frequency<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Audit coverage (critical journeys)<\/td>\n<td>% of defined critical user journeys audited within timeframe<\/td>\n<td>Ensures focus on highest-risk experiences<\/td>\n<td>80\u2013100% of critical journeys audited annually; top 10 quarterly<\/td>\n<td>Monthly\/Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Component compliance rate<\/td>\n<td>% of design system components meeting defined accessibility contract<\/td>\n<td>Scales accessibility via reuse<\/td>\n<td>70% \u2192 90% compliant within 2 quarters<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>High-severity issue backlog<\/td>\n<td>Count of open critical\/high issues across audited scope<\/td>\n<td>Indicates risk and remediation load<\/td>\n<td>Downward trend; no critical issues &gt; 30 days old<\/td>\n<td>Weekly\/Monthly<\/td>\n<\/tr>\n<tr>\n<td>Time to remediate (TTR) high severity<\/td>\n<td>Median days from ticket creation to verified fix<\/td>\n<td>Reduces risk exposure<\/td>\n<td>&lt; 30 days median for high severity (context-dependent)<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Escaped accessibility defects<\/td>\n<td># of accessibility defects found in production post-release<\/td>\n<td>Tracks prevention effectiveness<\/td>\n<td>30\u201350% reduction YoY; near-zero critical escapes<\/td>\n<td>Monthly\/Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Automated a11y test coverage<\/td>\n<td>% of key routes\/components covered by automated checks<\/td>\n<td>Improves early detection<\/td>\n<td>+10\u201320% coverage per quarter until stable<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Automated test signal quality<\/td>\n<td>Ratio of true positives to total findings; false positive rate<\/td>\n<td>Prevents \u201ctool fatigue\u201d and ignored results<\/td>\n<td>&gt;80% actionable findings; &lt;20% false positives<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Accessibility readiness compliance<\/td>\n<td>% of releases meeting defined readiness checks<\/td>\n<td>Operationalizes governance<\/td>\n<td>90%+ releases meet readiness criteria<\/td>\n<td>Per release\/Monthly<\/td>\n<\/tr>\n<tr>\n<td>Training completion (role-based)<\/td>\n<td>% of target audience completing training path<\/td>\n<td>Builds capability<\/td>\n<td>80% completion within 6 months of rollout<\/td>\n<td>Monthly\/Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Accessibility consultation throughput<\/td>\n<td># of consults\/reviews completed with documented outcomes<\/td>\n<td>Measures enablement activity<\/td>\n<td>Depends on org size; track trend and cycle time<\/td>\n<td>Weekly\/Monthly<\/td>\n<\/tr>\n<tr>\n<td>PR review adoption (a11y)<\/td>\n<td>% of a11y-sensitive PRs receiving review or checklist sign-off<\/td>\n<td>Embeds quality into workflow<\/td>\n<td>70%+ for high-risk repos<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Customer accessibility escalations<\/td>\n<td># and severity of customer escalations\/complaints<\/td>\n<td>External risk signal<\/td>\n<td>Downward trend; fast response time<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Stakeholder satisfaction<\/td>\n<td>Survey score from Product\/Design\/Engineering on usefulness and clarity<\/td>\n<td>Ensures influence and partnership<\/td>\n<td>\u2265 4.2\/5 average<\/td>\n<td>Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Exception\/waiver volume and age<\/td>\n<td># of active exceptions and time until closure<\/td>\n<td>Prevents permanent \u201cwaivers\u201d<\/td>\n<td>All exceptions time-bound; &lt;10% overdue<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Accessibility guild engagement<\/td>\n<td>Attendance and contributions (patterns, fixes, champions)<\/td>\n<td>Measures cultural adoption<\/td>\n<td>Stable participation; new champions quarterly<\/td>\n<td>Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Risk posture reporting timeliness<\/td>\n<td>On-time delivery of posture reports and audit evidence<\/td>\n<td>Audit readiness and leadership trust<\/td>\n<td>100% on-time for agreed cadence<\/td>\n<td>Monthly\/Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Design-to-dev handoff quality<\/td>\n<td>% of designs meeting a11y checklist pre-build<\/td>\n<td>Shifts left, reduces rework<\/td>\n<td>70% \u2192 90% within 2 quarters<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<p>Notes on measurement:\n&#8211; \u201cCompliance rate\u201d should be tied to <strong>defined scope and contracts<\/strong>, not vague claims of \u201cfully accessible.\u201d\n&#8211; Pair metrics to avoid perverse incentives (e.g., audit volume without remediation outcomes).\n&#8211; Use severity definitions aligned to user impact and legal risk (e.g., \u201cblocks task completion with keyboard\/screen reader\u201d).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">8) Technical Skills Required<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Must-have technical skills<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>WCAG 2.1\/2.2 and accessibility principles<\/strong><br\/>\n   &#8211; Description: Deep understanding of WCAG success criteria, POUR principles, and practical interpretations.<br\/>\n   &#8211; Use: Defining standards, auditing, acceptance criteria, remediation guidance.<br\/>\n   &#8211; Importance: <strong>Critical<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Semantic HTML and accessible web architecture<\/strong><br\/>\n   &#8211; Description: Correct use of headings, landmarks, forms, buttons\/links, tables, and native controls.<br\/>\n   &#8211; Use: Reviewing implementations, guiding engineers, creating reference patterns.<br\/>\n   &#8211; Importance: <strong>Critical<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>ARIA (appropriate use and anti-patterns)<\/strong><br\/>\n   &#8211; Description: Knowledge of ARIA roles\/states\/properties, name\/role\/value, and when <em>not<\/em> to use ARIA.<br\/>\n   &#8211; Use: Complex widgets, dynamic content, announcements, component contracts.<br\/>\n   &#8211; Importance: <strong>Critical<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Keyboard accessibility and focus management<\/strong><br\/>\n   &#8211; Description: Focus order, visible focus, focus trapping, roving tabindex, skip links, and modality behavior.<br\/>\n   &#8211; Use: Audits and remediation for navigation, modals, menus, and data-heavy screens.<br\/>\n   &#8211; Importance: <strong>Critical<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Screen reader testing proficiency<\/strong><br\/>\n   &#8211; Description: Ability to test flows with NVDA\/JAWS\/VoiceOver\/TalkBack and interpret results reliably.<br\/>\n   &#8211; Use: Manual verification, severity classification, evidence collection.<br\/>\n   &#8211; Importance: <strong>Critical<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Accessible forms and validation patterns<\/strong><br\/>\n   &#8211; Description: Labels, instructions, error messaging, error summaries, required fields, input masks considerations.<br\/>\n   &#8211; Use: Most common enterprise UI risk area; recurring guidance.<br\/>\n   &#8211; Importance: <strong>Critical<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Accessibility auditing and reporting<\/strong><br\/>\n   &#8211; Description: Methodical auditing, sampling, documenting issues, and mapping to standards.<br\/>\n   &#8211; Use: Audit plans, reports, backlog creation, evidence for compliance.<br\/>\n   &#8211; Importance: <strong>Critical<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Front-end engineering literacy<\/strong> (not necessarily full-time coding)<br\/>\n   &#8211; Description: Reading code, understanding component frameworks, advising on implementation trade-offs.<br\/>\n   &#8211; Use: PR reviews, design system collaboration, debugging accessibility issues.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Good-to-have technical skills<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>JavaScript\/TypeScript and modern UI frameworks (e.g., React)<\/strong><br\/>\n   &#8211; Use: Working effectively with component teams and test tooling.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Mobile accessibility fundamentals (iOS\/Android)<\/strong><br\/>\n   &#8211; Use: Advising on native control usage, gestures, dynamic type, and screen reader behavior on mobile.<br\/>\n   &#8211; Importance: <strong>Important<\/strong> (Critical if mobile-first)<\/p>\n<\/li>\n<li>\n<p><strong>Test automation familiarity (unit\/integration\/E2E)<\/strong><br\/>\n   &#8211; Use: Partnering with QE on where to test accessibility and how to keep checks reliable.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Color\/contrast and visual accessibility<\/strong><br\/>\n   &#8211; Use: Working with design on palettes, tokens, and theming.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Document accessibility basics (PDF\/Office)<\/strong><br\/>\n   &#8211; Use: If the product includes reports\/exports or customer communications.<br\/>\n   &#8211; Importance: <strong>Optional \/ Context-specific<\/strong><\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Advanced or expert-level technical skills<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Complex widget accessibility<\/strong><br\/>\n   &#8211; Description: Data grids, tree views, comboboxes, drag-and-drop, rich text editors, charts with alternatives.<br\/>\n   &#8211; Use: High-complexity enterprise UIs and design system components.<br\/>\n   &#8211; Importance: <strong>Important<\/strong> (often differentiator at Lead level)<\/p>\n<\/li>\n<li>\n<p><strong>Assistive tech and browser\/platform quirks<\/strong><br\/>\n   &#8211; Description: Differences across screen readers, browsers, OS settings, and their impact on UX.<br\/>\n   &#8211; Use: Diagnosing tricky issues and guiding robust fixes.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Accessibility tooling integration<\/strong><br\/>\n   &#8211; Description: Implementing and tuning axe-core\/linting rules, CI gates, reporting pipelines, baseline snapshots.<br\/>\n   &#8211; Use: Scaled prevention and metrics.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Regulatory and procurement standards mapping<\/strong><br\/>\n   &#8211; Description: Mapping WCAG to standards like Section 508 \/ EN 301 549, and contributing to conformance reporting.<br\/>\n   &#8211; Use: Enterprise sales and compliance readiness.<br\/>\n   &#8211; Importance: <strong>Context-specific<\/strong> (Critical in regulated markets)<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Emerging future skills for this role (next 2\u20135 years)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Accessibility for AI-driven interfaces<\/strong> (chat UIs, copilots, generated content)<br\/>\n   &#8211; Use: Ensuring generated UI\/content remains accessible and predictable.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Continuous accessibility monitoring<\/strong> (beyond audits)<br\/>\n   &#8211; Use: Ongoing detection of regressions and drift across large UI surfaces.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Design token governance for accessibility<\/strong><br\/>\n   &#8211; Use: Enforcing contrast, typography, and motion via tokens and linting.<br\/>\n   &#8211; Importance: <strong>Important<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>Inclusive research and analytics signals<\/strong><br\/>\n   &#8211; Use: Combining qual\/quant signals (support data, funnel drop-offs) to identify accessibility pain points.<br\/>\n   &#8211; Importance: <strong>Optional \/ Context-specific<\/strong><\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">9) Soft Skills and Behavioral Capabilities<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Influence without authority<\/strong><br\/>\n   &#8211; Why it matters: The role depends on adoption by multiple teams with different priorities.<br\/>\n   &#8211; On the job: Aligning Product\/Engineering on remediation scope; negotiating release readiness.<br\/>\n   &#8211; Strong performance: Gains commitment through clear risk framing, user impact evidence, and pragmatic solutions.<\/p>\n<\/li>\n<li>\n<p><strong>Clear technical communication (written and verbal)<\/strong><br\/>\n   &#8211; Why it matters: Accessibility issues are often subtle; ambiguous tickets lead to rework.<br\/>\n   &#8211; On the job: Writing audit findings, acceptance criteria, and component contracts.<br\/>\n   &#8211; Strong performance: Produces crisp, testable requirements and reproducible defect reports.<\/p>\n<\/li>\n<li>\n<p><strong>Pragmatic judgment and prioritization<\/strong><br\/>\n   &#8211; Why it matters: Not every issue can be fixed immediately; focus must track user impact and risk.<br\/>\n   &#8211; On the job: Severity scoring, remediation sequencing, deciding when to seek exceptions.<br\/>\n   &#8211; Strong performance: Consistently prioritizes what materially improves user access and reduces risk.<\/p>\n<\/li>\n<li>\n<p><strong>Empathy for users and inclusive mindset<\/strong><br\/>\n   &#8211; Why it matters: Accessibility is fundamentally about user outcomes, not checklists.<br\/>\n   &#8211; On the job: Advocating for usable patterns, not just technically passing criteria.<br\/>\n   &#8211; Strong performance: Connects requirements to real user scenarios; avoids \u201cminimum compliance\u201d thinking.<\/p>\n<\/li>\n<li>\n<p><strong>Coaching and enablement orientation<\/strong><br\/>\n   &#8211; Why it matters: A lead specialist must scale their impact through others.<br\/>\n   &#8211; On the job: Training sessions, PR feedback, pairing with engineers\/designers.<br\/>\n   &#8211; Strong performance: Teams become more capable and require fewer repeated interventions.<\/p>\n<\/li>\n<li>\n<p><strong>Conflict navigation and stakeholder management<\/strong><br\/>\n   &#8211; Why it matters: Accessibility often competes with deadlines and scope.<br\/>\n   &#8211; On the job: Handling pushback, negotiating time, escalating appropriately.<br\/>\n   &#8211; Strong performance: Maintains trust while holding the line on critical user access.<\/p>\n<\/li>\n<li>\n<p><strong>Systems thinking<\/strong><br\/>\n   &#8211; Why it matters: Fixing issues one-by-one doesn\u2019t scale; patterns and platforms do.<br\/>\n   &#8211; On the job: Driving design system changes and process gates.<br\/>\n   &#8211; Strong performance: Identifies root causes and implements durable prevention mechanisms.<\/p>\n<\/li>\n<li>\n<p><strong>Attention to detail<\/strong><br\/>\n   &#8211; Why it matters: Small differences in labels, focus order, and ARIA can break usability.<br\/>\n   &#8211; On the job: Manual testing, audit evidence, verifying fixes.<br\/>\n   &#8211; Strong performance: Catches nuanced issues and confirms fixes across platforms.<\/p>\n<\/li>\n<li>\n<p><strong>Resilience and calm under pressure<\/strong><br\/>\n   &#8211; Why it matters: Customer escalations and compliance deadlines can be high-stakes.<br\/>\n   &#8211; On the job: Rapid triage, executive updates, guiding hotfixes.<br\/>\n   &#8211; Strong performance: Creates structure in ambiguity and maintains quality under time constraints.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">10) Tools, Platforms, and Software<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Category<\/th>\n<th>Tool \/ platform \/ software<\/th>\n<th>Primary use<\/th>\n<th>Common \/ Optional \/ Context-specific<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Accessibility testing (automated)<\/td>\n<td><strong>axe DevTools \/ axe-core<\/strong><\/td>\n<td>Automated rule checks in browser and CI; developer workflow<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (manual assist)<\/td>\n<td><strong>Accessibility Insights<\/strong><\/td>\n<td>Guided manual checks, issue tracking, keyboard and tab stops<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (web)<\/td>\n<td><strong>Lighthouse<\/strong><\/td>\n<td>Baseline accessibility scoring and quick checks<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (web)<\/td>\n<td><strong>WAVE<\/strong><\/td>\n<td>Spot checks and visual overlays for common issues<\/td>\n<td>Optional<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (CI)<\/td>\n<td><strong>Pa11y<\/strong><\/td>\n<td>CLI-based automated checks; CI integration<\/td>\n<td>Optional \/ Context-specific<\/td>\n<\/tr>\n<tr>\n<td>Screen readers<\/td>\n<td><strong>NVDA<\/strong><\/td>\n<td>Windows screen reader testing (common baseline)<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Screen readers<\/td>\n<td><strong>JAWS<\/strong><\/td>\n<td>Enterprise Windows screen reader testing<\/td>\n<td>Context-specific (often Common in enterprise)<\/td>\n<\/tr>\n<tr>\n<td>Screen readers<\/td>\n<td><strong>VoiceOver (macOS\/iOS)<\/strong><\/td>\n<td>Apple platform testing<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Screen readers<\/td>\n<td><strong>TalkBack (Android)<\/strong><\/td>\n<td>Android testing<\/td>\n<td>Common (if mobile)<\/td>\n<\/tr>\n<tr>\n<td>Browser dev tools<\/td>\n<td>Chrome\/Edge\/Firefox DevTools<\/td>\n<td>Inspect semantics, accessibility tree, focus, ARIA<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Design tools<\/td>\n<td><strong>Figma<\/strong><\/td>\n<td>Design review: contrast, structure, component usage guidance<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Design system<\/td>\n<td><strong>Storybook<\/strong><\/td>\n<td>Component documentation and testing surface<\/td>\n<td>Common (for component-driven orgs)<\/td>\n<\/tr>\n<tr>\n<td>Front-end frameworks<\/td>\n<td>React \/ Angular \/ Vue<\/td>\n<td>Understanding implementation patterns<\/td>\n<td>Context-specific<\/td>\n<\/tr>\n<tr>\n<td>Source control<\/td>\n<td>GitHub \/ GitLab \/ Bitbucket<\/td>\n<td>PR reviews; code collaboration<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>CI\/CD<\/td>\n<td>GitHub Actions \/ GitLab CI \/ Jenkins \/ Azure DevOps<\/td>\n<td>Running automated checks; quality gates<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Testing (E2E)<\/td>\n<td>Cypress \/ Playwright \/ Selenium<\/td>\n<td>Integrating a11y checks into E2E flows<\/td>\n<td>Optional \/ Context-specific<\/td>\n<\/tr>\n<tr>\n<td>Testing (unit)<\/td>\n<td>Jest \/ Testing Library<\/td>\n<td>Component-level accessibility assertions<\/td>\n<td>Optional<\/td>\n<\/tr>\n<tr>\n<td>Linting<\/td>\n<td>eslint-plugin-jsx-a11y<\/td>\n<td>Preventing common issues in development<\/td>\n<td>Common (for React)<\/td>\n<\/tr>\n<tr>\n<td>Issue tracking<\/td>\n<td>Jira \/ Azure Boards<\/td>\n<td>Backlog, remediation tracking, reporting<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Documentation<\/td>\n<td>Confluence \/ Notion \/ SharePoint<\/td>\n<td>Standards, audit reports, guidance repository<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Collaboration<\/td>\n<td>Slack \/ Microsoft Teams<\/td>\n<td>Intake, office hours, quick consults<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Analytics (product)<\/td>\n<td>Amplitude \/ GA \/ Adobe Analytics<\/td>\n<td>Finding high-impact flows; correlating UX issues<\/td>\n<td>Optional<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>Datadog \/ New Relic<\/td>\n<td>Not primary; context for incident response<\/td>\n<td>Context-specific<\/td>\n<\/tr>\n<tr>\n<td>Compliance documentation<\/td>\n<td>VPAT\/ACR templates (vendor or internal)<\/td>\n<td>Conformance reporting support<\/td>\n<td>Context-specific<\/td>\n<\/tr>\n<tr>\n<td>Color tools<\/td>\n<td>Colour Contrast Analyser \/ Stark<\/td>\n<td>Contrast checks and design review<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Prototyping<\/td>\n<td>Figma prototypes \/ Framer (varies)<\/td>\n<td>Testing interactions early<\/td>\n<td>Optional<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">11) Typical Tech Stack \/ Environment<\/h2>\n\n\n\n<p><strong>Infrastructure environment<\/strong>\n&#8211; Cloud-hosted SaaS products are common (AWS\/Azure\/GCP), but this role is largely platform-agnostic.\n&#8211; Environments include development, staging, and production with standard release pipelines.<\/p>\n\n\n\n<p><strong>Application environment<\/strong>\n&#8211; Web applications: SPA frameworks (often React) with shared design systems and component libraries.\n&#8211; Mobile applications: native iOS\/Android or cross-platform (React Native\/Flutter), depending on company.\n&#8211; Internal admin tools and customer portals often have complex forms, tables, and dashboards\u2014high accessibility risk.<\/p>\n\n\n\n<p><strong>Data environment<\/strong>\n&#8211; Product analytics may inform prioritization (most-used flows, drop-offs), but accessibility testing is primarily UX\/engineering driven.\n&#8211; Exported reports (PDF\/CSV) may introduce document accessibility needs in some contexts.<\/p>\n\n\n\n<p><strong>Security environment<\/strong>\n&#8211; Standard enterprise security controls; accessibility tools must be approved where necessary.\n&#8211; Customer data handling influences how audits are performed (use test accounts\/sanitized datasets).<\/p>\n\n\n\n<p><strong>Delivery model<\/strong>\n&#8211; Agile\/Scrum or Kanban teams with CI\/CD pipelines and frequent releases.\n&#8211; Accessibility should be embedded via:\n  &#8211; Design review gates for high-impact UI\n  &#8211; PR checks and component-level contracts\n  &#8211; QE validation for critical flows<\/p>\n\n\n\n<p><strong>Agile\/SDLC context<\/strong>\n&#8211; Shift-left expectations: accessibility considered from discovery through build and test.\n&#8211; Definition of Done includes accessibility verification steps proportional to risk.<\/p>\n\n\n\n<p><strong>Scale\/complexity context<\/strong>\n&#8211; Multiple teams and repositories; federated ownership.\n&#8211; A design system\/UI platform team is common; where absent, the Lead Accessibility Specialist often helps bootstrap one.<\/p>\n\n\n\n<p><strong>Team topology<\/strong>\n&#8211; Typically a senior IC within Experience Engineering:\n  &#8211; Partners with Design System lead, Front-End leads, QE lead, UX Research\n  &#8211; May have dotted-line influence across product teams via \u201caccessibility champions\u201d<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">12) Stakeholders and Collaboration Map<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Internal stakeholders<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Head\/Director of Experience Engineering (likely manager\/reporting line):<\/strong> sets quality expectations, prioritization support, escalations.<\/li>\n<li><strong>Design System \/ UI Platform team:<\/strong> primary partner for scalable, reusable accessibility improvements.<\/li>\n<li><strong>Product Design \/ UX:<\/strong> alignment on interaction patterns, visuals (contrast, focus), content structure, motion.<\/li>\n<li><strong>Front-End Engineering leads:<\/strong> implementation feasibility, technical debt planning, PR review pathways.<\/li>\n<li><strong>Mobile Engineering leads:<\/strong> platform-specific accessibility patterns and testing.<\/li>\n<li><strong>Quality Engineering (QE):<\/strong> integrating checks into automated and manual testing practices.<\/li>\n<li><strong>Product Managers:<\/strong> prioritization, acceptance criteria, roadmap trade-offs.<\/li>\n<li><strong>Legal\/Compliance\/Risk:<\/strong> regulatory expectations, exception governance, audit readiness.<\/li>\n<li><strong>Customer Support \/ Customer Success:<\/strong> escalations, customer-reported accessibility issues, workaround communications.<\/li>\n<li><strong>Sales Engineering \/ Procurement support:<\/strong> RFPs, accessibility questionnaires, enterprise deal blockers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">External stakeholders (as applicable)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Third-party vendors:<\/strong> UI libraries, analytics tools, embedded widgets; accessibility posture and remediation commitments.<\/li>\n<li><strong>External auditors\/consultants:<\/strong> periodic independent audits; the role coordinates evidence and remediation follow-up.<\/li>\n<li><strong>Enterprise customers:<\/strong> accessibility requirements, procurement standards, verification requests.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Peer roles<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>UX Engineer, Design Technologist, Front-End Staff Engineer, QE Lead, Product Operations, Content Designer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Upstream dependencies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Design system maturity and component reuse adoption.<\/li>\n<li>Product roadmap stability and resourcing for remediation.<\/li>\n<li>Tooling approvals and CI\/CD ownership.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Downstream consumers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Product teams using accessibility standards, component contracts, and patterns.<\/li>\n<li>Legal\/Compliance relying on evidence and posture reporting.<\/li>\n<li>Customer-facing teams relying on credible accessibility statements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Nature of collaboration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Partnership model: the Lead Accessibility Specialist provides standards, audits, enablement, and verification; delivery teams own fixes.<\/li>\n<li>Emphasis on co-creation: pairing on tricky issues, improving shared components.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical decision-making authority<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advisory authority on standards, severity, testing approach.<\/li>\n<li>Shared decision-making on remediation priority with Product\/Engineering.<\/li>\n<li>Escalation authority for critical user access blockers or regulatory risk.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Escalation points<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Repeated non-compliance with accessibility readiness criteria.<\/li>\n<li>Unresolved critical defects approaching release.<\/li>\n<li>Legal\/compliance deadlines, customer complaints, or formal notices.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13) Decision Rights and Scope of Authority<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Can decide independently<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility testing methodology and audit approach (sampling, severity rubric, evidence format).<\/li>\n<li>Accessibility guidance and interpretation notes (within recognized standards).<\/li>\n<li>Recommendations for component contracts and interaction patterns.<\/li>\n<li>Triage classification for accessibility findings (severity, affected users, reproduction steps).<\/li>\n<li>Training content, office hours structure, and enablement materials.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Requires team approval (cross-functional)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility readiness gates added to SDLC (DoD changes, release checklists).<\/li>\n<li>CI\/CD checks that may block builds (thresholds, enforcement, rollout plan).<\/li>\n<li>Design system backlog priorities that affect multiple consumers.<\/li>\n<li>Standardized acceptance criteria templates used across teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Requires manager\/director\/executive approval<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official policy statements and compliance commitments (public claims, contractual language).<\/li>\n<li>Risk acceptance for exceptions\/waivers beyond defined thresholds (e.g., critical issues with delayed remediation).<\/li>\n<li>Budget for tooling, external audits, training vendors, or significant remediation initiatives.<\/li>\n<li>Staffing decisions (adding accessibility specialists, QE support, or dedicated remediation squads).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Budget \/ vendor authority (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Recommends tools\/vendors (e.g., Deque, audit services), participates in evaluation.<\/li>\n<li>Final procurement usually sits with Engineering leadership\/Procurement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture \/ delivery authority (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Influences UI architecture decisions where accessibility is impacted (routing, focus management strategy, component APIs).<\/li>\n<li>Does not typically own product architecture, but can escalate when architectural choices create systemic accessibility risk.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hiring authority (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>May participate in interviews and set assessment standards for accessibility-related roles.<\/li>\n<li>Typically not the final hiring decision-maker unless also a people manager.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14) Required Experience and Qualifications<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Typical years of experience<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>7\u201312 years<\/strong> in UX engineering, front-end engineering, QA accessibility, inclusive design, or dedicated digital accessibility roles.<\/li>\n<li>At least <strong>3\u20135 years<\/strong> of hands-on, primary responsibility for accessibility outcomes (auditing, remediation guidance, governance).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Education expectations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Bachelor\u2019s degree in a related field (HCI, Computer Science, Design, Information Systems) is common but not mandatory.<\/li>\n<li>Equivalent experience with demonstrable outcomes is often acceptable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certifications (relevant, not always required)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAAP CPACC<\/strong> (Common; strong signal for broad accessibility knowledge)<\/li>\n<li><strong>IAAP WAS<\/strong> (Web Accessibility Specialist) (Optional but valuable)<\/li>\n<li><strong>Deque University certifications<\/strong> (Context-specific; valuable where Deque tooling is used)<\/li>\n<li>Any certification should be weighed alongside demonstrated practical ability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prior role backgrounds commonly seen<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility Specialist \/ Consultant<\/li>\n<li>Senior Front-End Engineer with accessibility focus<\/li>\n<li>UX Engineer \/ Design Technologist<\/li>\n<li>QA Engineer specializing in accessibility<\/li>\n<li>Design System Engineer with strong accessibility ownership<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Domain knowledge expectations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enterprise SaaS patterns (complex forms, permissions, data tables)<\/li>\n<li>Accessibility legal\/regulatory landscape awareness (without needing to be legal counsel)<\/li>\n<li>Procurement\/RFP dynamics for enterprise accessibility requirements (context-specific)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Leadership experience expectations (Lead-level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Leading accessibility initiatives across multiple teams or products.<\/li>\n<li>Mentoring and enabling others (training, standards, playbooks).<\/li>\n<li>Demonstrated cross-functional influence and program shaping.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">15) Career Path and Progression<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Common feeder roles into this role<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Senior Accessibility Specialist<\/li>\n<li>Senior UX Engineer \/ UI Engineer<\/li>\n<li>Senior Front-End Engineer with accessibility ownership<\/li>\n<li>QE Lead\/Staff with accessibility specialization<\/li>\n<li>Design System Engineer (senior) with strong inclusive design focus<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Next likely roles after this role<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Principal Accessibility Specialist \/ Staff Accessibility Engineer<\/strong> (greater org-wide scope, deeper systems leverage)<\/li>\n<li><strong>Accessibility Program Manager \/ Accessibility Lead (Program)<\/strong> (broader governance, policy, and enterprise coordination)<\/li>\n<li><strong>Design System Lead \/ UI Platform Lead<\/strong> (if technical and platform-oriented)<\/li>\n<li><strong>Experience Engineering Manager<\/strong> (if moving into people leadership)<\/li>\n<li><strong>Director of Experience Quality \/ Inclusive Experience<\/strong> (in mature orgs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Adjacent career paths<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Inclusive Design Lead (design-led accessibility and research)<\/li>\n<li>UX Research specialization in inclusive methods<\/li>\n<li>Product Quality\/Operational Excellence roles<\/li>\n<li>Technical Product Management for design systems \/ developer experience<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Skills needed for promotion (Lead \u2192 Principal\/Staff)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Proven ability to deliver <strong>org-wide<\/strong> outcomes, not just project-level wins.<\/li>\n<li>Stronger systems leverage: design tokens, component governance, CI quality gates at scale.<\/li>\n<li>Advanced stakeholder leadership: executives, Legal, procurement, enterprise customers.<\/li>\n<li>Strategic program building: multi-quarter roadmap, measurable KPIs, operating model maturity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How this role evolves over time<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Early phase: auditing, triage, foundational standards, and quick wins.<\/li>\n<li>Mid phase: design system contracts, automated checks, process gates, and capability building.<\/li>\n<li>Mature phase: continuous monitoring, advanced patterns, audit readiness, and strategic differentiation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16) Risks, Challenges, and Failure Modes<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Common role challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Late discovery of issues:<\/strong> accessibility found near release due to missing shift-left practices.<\/li>\n<li><strong>Tool overreliance:<\/strong> teams assume automated scans equal compliance.<\/li>\n<li><strong>Distributed ownership:<\/strong> many teams ship UI, making governance and consistency difficult.<\/li>\n<li><strong>Conflicting priorities:<\/strong> deadlines compete with remediation work and foundational refactors.<\/li>\n<li><strong>Ambiguity of \u201cdone\u201d:<\/strong> unclear acceptance criteria and inconsistent verification.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Bottlenecks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limited design system adoption (teams build custom UI, increasing variability).<\/li>\n<li>Lack of QE capacity for assistive tech regression testing.<\/li>\n<li>CI\/CD ownership constraints (difficulty adding or enforcing checks).<\/li>\n<li>Sparse product analytics or unclear \u201ccritical journey\u201d definitions, making prioritization harder.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Anti-patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201cAccessibility as a phase\u201d (only audited at the end).<\/li>\n<li>\u201cCheckbox compliance\u201d (passing a tool score while usability remains poor).<\/li>\n<li>Excessive ARIA and custom widgets when native controls would work.<\/li>\n<li>Writing vague tickets (\u201cfix accessibility\u201d) without reproduction steps and test criteria.<\/li>\n<li>Waivers without deadlines, owners, or mitigations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common reasons for underperformance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Inability to influence: communicates as a gatekeeper rather than an enabler.<\/li>\n<li>Insufficient technical depth to guide real remediation.<\/li>\n<li>Poor prioritization: focuses on low-impact issues while critical blockers persist.<\/li>\n<li>Inconsistent documentation and evidence collection, weakening trust and audit readiness.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Business risks if this role is ineffective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Legal exposure (complaints, litigation, settlement costs) depending on market and customer base.<\/li>\n<li>Enterprise sales friction (failed accessibility requirements, delayed procurement).<\/li>\n<li>Customer churn and reputational harm.<\/li>\n<li>Increased engineering cost due to late remediation and repeated regressions.<\/li>\n<li>Reduced usability and higher support burden for all users, not only users with disabilities.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">17) Role Variants<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">By company size<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Startup \/ small scale:<\/strong> <\/li>\n<li>Role is more hands-on: direct remediation, component building, and rapid guidance.  <\/li>\n<li>Governance is lighter; focus is on building foundational patterns and avoiding bad debt.<\/li>\n<li><strong>Mid-size product org:<\/strong> <\/li>\n<li>Balanced: audits + enablement + design system partnership + some tooling integration.  <\/li>\n<li>Clear KPIs and quarterly reporting become important.<\/li>\n<li><strong>Large enterprise:<\/strong> <\/li>\n<li>Strong governance, audit readiness, multi-product coordination, and vendor management.  <\/li>\n<li>Often includes formal exception processes, conformance reporting, and external audit coordination.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">By industry<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Public sector \/ education:<\/strong> strong compliance expectations; conformance reporting and procurement standards are central.<\/li>\n<li><strong>Finance \/ healthcare:<\/strong> higher regulatory scrutiny; risk management and documentation are heavier; more formal testing evidence.<\/li>\n<li><strong>B2B SaaS:<\/strong> enterprise procurement questionnaires and VPAT\/ACR support become frequent.<\/li>\n<li><strong>B2C:<\/strong> scale and brand risk; focus on critical journeys, mobile accessibility, and continuous regression prevention.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">By geography<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standards and enforcement vary:<\/li>\n<li>US: ADA\/Section 508 dynamics<\/li>\n<li>EU: EN 301 549 and regional requirements<\/li>\n<li>Global: multi-standard mapping may be required<br\/>\n  The role should note claims carefully and coordinate with Legal for region-specific commitments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Product-led vs service-led company<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Product-led:<\/strong> focus on design system, CI checks, scalable patterns, and consistent release readiness.<\/li>\n<li><strong>Service-led \/ IT delivery:<\/strong> focus on project-based audits, client requirements, and handover documentation; more variability across stacks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup vs enterprise maturity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Lower maturity:<\/strong> build baseline standards, quick wins, and guardrails; avoid heavy bureaucracy.<\/li>\n<li><strong>Higher maturity:<\/strong> continuous monitoring, dashboards, formal audit cycles, and evidence governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regulated vs non-regulated environment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regulated:<\/strong> stronger documentation, approvals, and formal exception management.<\/li>\n<li><strong>Non-regulated:<\/strong> still needs standards and testing, but can optimize for speed and user impact over formal artifacts.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">18) AI \/ Automation Impact on the Role<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Tasks that can be automated (or heavily assisted)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Initial detection<\/strong> of common WCAG failures via automated rules (missing labels, contrast issues, ARIA attribute misuse, landmark gaps).<\/li>\n<li><strong>Regression detection<\/strong> in CI for known components\/routes (baseline comparisons, rule enforcement).<\/li>\n<li><strong>Drafting artifacts<\/strong>: AI-assisted creation of first-pass audit summaries, ticket templates, acceptance criteria drafts (requires expert review).<\/li>\n<li><strong>Knowledge retrieval<\/strong>: faster lookup of prior decisions, patterns, and internal guidance via AI search over documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tasks that remain human-critical<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Usability with assistive tech:<\/strong> screen reader experience quality, clarity of announcements, navigation efficiency, and cognitive load.<\/li>\n<li><strong>Interpreting standards in context:<\/strong> determining severity, user impact, and appropriate remediation for complex UI.<\/li>\n<li><strong>Design trade-offs:<\/strong> balancing interaction design, visual hierarchy, and business goals while maintaining accessibility.<\/li>\n<li><strong>Stakeholder influence:<\/strong> negotiation, risk framing, training, and cultural adoption.<\/li>\n<li><strong>Governance and accountability:<\/strong> exception approvals, compliance statements, and evidence credibility.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How AI changes the role over the next 2\u20135 years<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The role shifts from \u201cfinding issues\u201d to <strong>designing systems that prevent issues<\/strong>:<\/li>\n<li>Continuous monitoring becomes more feasible<\/li>\n<li>Greater emphasis on component contracts, tokens, and automated enforcement<\/li>\n<li>Increased expectation to govern accessibility of <strong>AI-generated experiences<\/strong>:<\/li>\n<li>Generated UI content must be structured and navigable<\/li>\n<li>Summaries, suggestions, and dynamic content must be perceivable and operable<\/li>\n<li>More sophisticated analysis:<\/li>\n<li>Correlating accessibility signals with product analytics and support data to target improvements<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">New expectations caused by AI, automation, or platform shifts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ability to evaluate AI tooling claims and avoid \u201ccompliance theater.\u201d<\/li>\n<li>Defining which checks are safe to gate in CI and which require manual verification.<\/li>\n<li>Maintaining trust: ensuring AI-assisted outputs are reviewed, accurate, and defensible.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">19) Hiring Evaluation Criteria<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to assess in interviews<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standards mastery + pragmatism:<\/strong> can they apply WCAG realistically, not recite it?<\/li>\n<li><strong>Manual testing depth:<\/strong> screen reader competency and ability to explain findings clearly.<\/li>\n<li><strong>Technical remediation guidance:<\/strong> can they propose implementable fixes aligned to modern frameworks?<\/li>\n<li><strong>Systems leverage:<\/strong> can they scale impact through design systems, tooling, and process?<\/li>\n<li><strong>Influence and leadership:<\/strong> can they drive adoption across teams without becoming a blocker?<\/li>\n<li><strong>Documentation quality:<\/strong> can they write audit findings and acceptance criteria that engineers can execute?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Practical exercises or case studies (recommended)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Live audit exercise (60\u201390 minutes):<\/strong><br\/>\n   &#8211; Provide a staging URL or recorded prototype of a form-heavy flow.<br\/>\n   &#8211; Candidate identifies top issues, severity, WCAG mapping, and remediation suggestions.<br\/>\n   &#8211; Evaluate clarity, prioritization, and correctness.<\/p>\n<\/li>\n<li>\n<p><strong>Component contract exercise (45\u201360 minutes):<\/strong><br\/>\n   &#8211; Present a \u201ccombobox\u201d or \u201cmodal dialog\u201d requirement.<br\/>\n   &#8211; Candidate defines keyboard behavior, focus management rules, and ARIA expectations.<br\/>\n   &#8211; Evaluate completeness and avoidance of common anti-patterns.<\/p>\n<\/li>\n<li>\n<p><strong>Influence scenario (30 minutes):<\/strong><br\/>\n   &#8211; Simulate a release readiness conflict: critical issue found late, team resists delaying release.<br\/>\n   &#8211; Candidate explains options (mitigation, rollback, scope change, exception process), escalation path, and communication.<\/p>\n<\/li>\n<li>\n<p><strong>Writing sample:<\/strong><br\/>\n   &#8211; Ask for a short audit finding ticket with reproduction steps, expected behavior, actual behavior, and acceptance criteria.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Strong candidate signals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Demonstrates real screen reader fluency (not just \u201cI ran a tool\u201d).<\/li>\n<li>Can explain <em>why<\/em> issues matter in user terms and business risk terms.<\/li>\n<li>Offers fixes that prefer native semantics and resilient patterns.<\/li>\n<li>Has experience improving a design system or enabling CI checks without blocking teams unfairly.<\/li>\n<li>Brings a portfolio of artifacts: guidelines, training, audits, dashboards, or evidence.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Weak candidate signals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Overfocus on automated scores and superficial checklists.<\/li>\n<li>Heavy ARIA usage without strong rationale; proposes brittle custom widgets.<\/li>\n<li>Struggles to prioritize or to define \u201cseverity\u201d based on user impact.<\/li>\n<li>Cannot translate findings into clear tickets or acceptance criteria.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Red flags<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treats accessibility as optional or \u201cbest effort.\u201d<\/li>\n<li>Dismisses user feedback or frames accessibility as purely compliance.<\/li>\n<li>Cannot explain the limits of automation or confuses WCAG conformance with usability.<\/li>\n<li>Adversarial stakeholder posture (\u201cmy job is to block releases\u201d).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scorecard dimensions (interview rubric)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Dimension<\/th>\n<th>What \u201cexcellent\u201d looks like<\/th>\n<th>Weight<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Accessibility expertise (WCAG + applied practice)<\/td>\n<td>Correct, nuanced, pragmatic application; avoids dogma<\/td>\n<td>High<\/td>\n<\/tr>\n<tr>\n<td>Manual testing (assistive tech)<\/td>\n<td>Fluent, confident, finds meaningful issues quickly<\/td>\n<td>High<\/td>\n<\/tr>\n<tr>\n<td>Technical remediation guidance<\/td>\n<td>Actionable solutions aligned to modern UI engineering<\/td>\n<td>High<\/td>\n<\/tr>\n<tr>\n<td>Systems thinking \/ scalability<\/td>\n<td>Design system, CI checks, process integration mindset<\/td>\n<td>High<\/td>\n<\/tr>\n<tr>\n<td>Communication &amp; documentation<\/td>\n<td>Clear, testable, engineer-ready outputs<\/td>\n<td>Medium-High<\/td>\n<\/tr>\n<tr>\n<td>Stakeholder influence<\/td>\n<td>Collaborative, risk-aware, solution-oriented<\/td>\n<td>Medium-High<\/td>\n<\/tr>\n<tr>\n<td>Program leadership (Lead level)<\/td>\n<td>Can run a roadmap, metrics, governance<\/td>\n<td>Medium<\/td>\n<\/tr>\n<tr>\n<td>Culture add \/ inclusive mindset<\/td>\n<td>Empathy, maturity, user-centered<\/td>\n<td>Medium<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20) Final Role Scorecard Summary<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Category<\/th>\n<th>Summary<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Role title<\/td>\n<td>Lead Accessibility Specialist<\/td>\n<\/tr>\n<tr>\n<td>Role purpose<\/td>\n<td>Ensure digital experiences meet accessibility standards and are usable by people with disabilities by embedding accessibility into design, engineering, QA, and governance across Experience Engineering.<\/td>\n<\/tr>\n<tr>\n<td>Top 10 responsibilities<\/td>\n<td>1) Define accessibility standards and guidance 2) Execute and operationalize audits 3) Prioritize remediation with Product\/Engineering 4) Create actionable backlog\/tickets 5) Enable accessible design and design reviews 6) Partner with design system to ship accessible components 7) Integrate automated checks into CI\/dev workflows 8) Verify fixes with manual assistive tech testing 9) Build training and run accessibility guild\/office hours 10) Support governance, exceptions, and conformance documentation inputs<\/td>\n<\/tr>\n<tr>\n<td>Top 10 technical skills<\/td>\n<td>1) WCAG 2.1\/2.2 application 2) Semantic HTML 3) ARIA (correct use) 4) Keyboard &amp; focus management 5) Screen reader testing (NVDA\/JAWS\/VoiceOver\/TalkBack) 6) Accessible forms &amp; validation 7) Auditing &amp; evidence writing 8) Front-end engineering literacy (JS frameworks) 9) Automated a11y testing integration (axe-core, CI) 10) Complex widget accessibility (tables\/combobox\/grids)<\/td>\n<\/tr>\n<tr>\n<td>Top 10 soft skills<\/td>\n<td>1) Influence without authority 2) Clear writing and structured communication 3) Pragmatic prioritization 4) Coaching\/enablement 5) Empathy and user advocacy 6) Stakeholder management 7) Systems thinking 8) Attention to detail 9) Conflict navigation 10) Resilience under escalation<\/td>\n<\/tr>\n<tr>\n<td>Top tools \/ platforms<\/td>\n<td>axe DevTools\/axe-core, Accessibility Insights, Lighthouse, NVDA, JAWS (context), VoiceOver, TalkBack, Browser DevTools, Figma, Storybook (context), Jira, Confluence\/Notion, GitHub\/GitLab, eslint-plugin-jsx-a11y, Cypress\/Playwright (context)<\/td>\n<\/tr>\n<tr>\n<td>Top KPIs<\/td>\n<td>Audit coverage of critical journeys, component compliance rate, high-severity backlog trend, time-to-remediate high severity, escaped defects, automated test coverage + signal quality, release readiness compliance, training completion, stakeholder satisfaction, exception volume\/age<\/td>\n<\/tr>\n<tr>\n<td>Main deliverables<\/td>\n<td>Accessibility standards\/guidelines, audit reports, remediation roadmap\/backlog, component contracts and pattern library, CI\/testing enablement docs, training materials, governance\/exception templates, metrics dashboard, conformance documentation inputs<\/td>\n<\/tr>\n<tr>\n<td>Main goals<\/td>\n<td>30\/60\/90-day baseline + operating cadence; 6-month scalable prevention (design system + CI + process); 12-month sustained conformance for defined scope with reduced escaped defects and audit readiness<\/td>\n<\/tr>\n<tr>\n<td>Career progression options<\/td>\n<td>Principal\/Staff Accessibility Specialist, Accessibility Program Manager, Design System\/UI Platform Lead, Experience Engineering Manager, Director of Experience Quality\/Inclusive Experience (org maturity dependent)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n","protected":false},"excerpt":{"rendered":"<p>The Lead Accessibility Specialist is the accountable subject-matter expert (SME) for ensuring that digital experiences\u2014web applications, mobile apps, internal tools, and customer-facing platforms\u2014are usable by people with disabilities and meet applicable accessibility standards. This role drives accessibility strategy and execution across Experience Engineering, embedding accessible design and engineering practices into product delivery so accessibility is built-in rather than audited-in later.<\/p>\n","protected":false},"author":61,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_joinchat":[],"footnotes":""},"categories":[24501,24508],"tags":[],"class_list":["post-75062","post","type-post","status-publish","format-standard","hentry","category-experience-engineering","category-specialist"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/75062","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/61"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=75062"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/75062\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=75062"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=75062"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=75062"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}