{"id":75060,"date":"2026-04-16T12:10:07","date_gmt":"2026-04-16T12:10:07","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/accessibility-specialist-role-blueprint-responsibilities-skills-kpis-and-career-path\/"},"modified":"2026-04-16T12:10:07","modified_gmt":"2026-04-16T12:10:07","slug":"accessibility-specialist-role-blueprint-responsibilities-skills-kpis-and-career-path","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/accessibility-specialist-role-blueprint-responsibilities-skills-kpis-and-career-path\/","title":{"rendered":"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>An <strong>Accessibility Specialist<\/strong> ensures that digital products and services are usable by people with disabilities and conform to relevant accessibility standards. In a software company or IT organization, this role reduces legal\/compliance risk, expands market reach, improves user experience quality, and enables teams to build accessibility in by default rather than treating it as a late-stage fix.<\/p>\n\n\n\n<p>This role exists because accessibility is both a <strong>product quality discipline<\/strong> (like security or performance) and a <strong>customer experience requirement<\/strong> that must be operationalized across design, engineering, QA, content, and support workflows. The business value is realized through measurable reductions in accessibility defects, faster remediation cycles, improved usability for all users, and demonstrable compliance (where required) with standards such as <strong>WCAG<\/strong> and regulations such as <strong>ADA\/Section 508\/EN 301 549<\/strong>.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Role horizon:<\/strong> Current (established and actively needed in modern software delivery)<\/li>\n<li><strong>Typical interaction partners:<\/strong> Product Management, UX\/UI Design, UX Research, Front-End Engineering, Mobile Engineering, QA\/Test Engineering, Design Systems teams, Content\/Technical Writing, Legal\/Compliance, Procurement\/Vendor Management, Customer Support, and Security\/GRC teams.<\/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><br\/>\nEmbed accessibility into the product development lifecycle so that user experiences are perceivable, operable, understandable, and robust for people using assistive technologies\u2014while enabling teams to deliver compliant, inclusive experiences at scale.<\/p>\n\n\n\n<p><strong>Strategic importance to the company:<\/strong>\n&#8211; Protects the organization from reputational and regulatory risk associated with inaccessible software.\n&#8211; Enables access to enterprise\/public-sector markets where accessibility compliance is required.\n&#8211; Improves overall experience quality, usability, and customer satisfaction (accessibility improvements often benefit all users).\n&#8211; Strengthens design system maturity and engineering standards, improving delivery velocity over time.<\/p>\n\n\n\n<p><strong>Primary business outcomes expected:<\/strong>\n&#8211; Consistent conformance to agreed accessibility targets (commonly <strong>WCAG 2.1 AA<\/strong> or <strong>WCAG 2.2 AA<\/strong>, depending on company policy and product commitments).\n&#8211; Reduced accessibility defect leakage to production and reduced remediation cost per release.\n&#8211; Increased accessibility capability across teams via standards, tooling, and training.\n&#8211; Credible evidence of accessibility posture for customers, audits, or procurement (e.g., VPAT where applicable).<\/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>Define accessibility quality targets<\/strong> (e.g., WCAG level and scope) with Experience Engineering leadership and Product leadership; translate them into actionable engineering and design expectations.<\/li>\n<li><strong>Establish accessibility governance<\/strong> across the SDLC (definition of done, acceptance criteria patterns, test gates, audit cadence, and escalation pathways).<\/li>\n<li><strong>Partner with Design Systems<\/strong> to ensure accessible components, tokens, patterns, and documentation are the default building blocks for teams.<\/li>\n<li><strong>Prioritize accessibility work<\/strong> with Product and Engineering by quantifying risk, user impact, and remediation effort; support roadmap trade-offs with clear evidence.<\/li>\n<li><strong>Influence vendor and third-party product decisions<\/strong> by defining accessibility requirements for procurement and evaluating compliance evidence (e.g., VPATs, audit reports).<\/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>Conduct accessibility audits<\/strong> of web and\/or mobile experiences using a combination of automated scans and manual testing (keyboard, screen reader, zoom\/reflow, color contrast, etc.).<\/li>\n<li><strong>Create and manage remediation plans<\/strong>: actionable findings, severity, reproduction steps, recommended fixes, owners, and timelines.<\/li>\n<li><strong>Triage accessibility issues<\/strong> reported by customers, support, QA, and internal teams; validate, prioritize, and route to the appropriate backlog.<\/li>\n<li><strong>Develop and deliver training<\/strong> for designers, engineers, QA, and content authors; provide role-specific guidance (e.g., accessible forms for engineers, accessible layouts for designers).<\/li>\n<li><strong>Maintain accessibility documentation<\/strong>: standards, checklists, coding patterns, ARIA guidance, content guidelines, and testing protocols.<\/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>Provide implementation guidance<\/strong> to engineers on semantic HTML, ARIA usage, focus management, accessible forms, error handling, and dynamic UI behaviors.<\/li>\n<li><strong>Support automated accessibility testing<\/strong> in CI\/CD (linting, unit\/integration checks, regression scans) and define what \u201cgood\u201d looks like for automation vs manual coverage.<\/li>\n<li><strong>Validate assistive technology compatibility<\/strong> for critical user journeys (screen readers such as NVDA\/JAWS\/VoiceOver, speech input as relevant, and keyboard-only operation).<\/li>\n<li><strong>Review UI changes<\/strong> (PR reviews or design reviews) for accessibility risks and propose practical fixes that align with system constraints and design intent.<\/li>\n<li><strong>Ensure accessible content patterns<\/strong> for microcopy, headings, link text, error messages, and content structure that supports navigation and comprehension.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Cross-functional or stakeholder responsibilities<\/h3>\n\n\n\n<ol class=\"wp-block-list\" start=\"16\">\n<li><strong>Collaborate with UX Research<\/strong> to include users with disabilities in research where feasible, and to translate findings into product improvements.<\/li>\n<li><strong>Work with Customer Support and Success<\/strong> to improve handling of accessibility-related tickets, communication templates, and escalation processes.<\/li>\n<li><strong>Support sales and solutions teams<\/strong> with credible accessibility statements, customer questionnaires, and technical explanations (within policy).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Governance, compliance, or quality responsibilities<\/h3>\n\n\n\n<ol class=\"wp-block-list\" start=\"19\">\n<li><strong>Map product requirements to relevant standards\/regulations<\/strong> (e.g., WCAG, Section 508, EN 301 549) and help ensure evidence is available for audits or customer requests.<\/li>\n<li><strong>Track accessibility quality metrics<\/strong> and report progress to Experience Engineering leadership and product governance forums.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Leadership responsibilities (applicable at this title level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This is primarily an <strong>individual contributor specialist<\/strong> role. Leadership is exercised through influence:<\/li>\n<li>Coaching teams and setting standards rather than managing people.<\/li>\n<li>Leading small cross-functional initiatives (e.g., \u201cAccessible Forms Initiative\u201d or \u201cKeyboard Navigation Baseline\u201d).<\/li>\n<\/ul>\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 new UI changes (designs or PRs) for accessibility risks; comment with specific, testable recommendations.<\/li>\n<li>Validate accessibility bug reports: reproduce issues, capture evidence (screenshots, DOM snippets, screen reader output), assign severity, and log actionable tickets.<\/li>\n<li>Provide office-hours style support to engineers\/designers on implementation questions (ARIA patterns, focus traps, modal dialogs, error summaries, etc.).<\/li>\n<li>Run quick checks on in-progress features using browser dev tools and accessibility tooling (e.g., axe DevTools) plus keyboard testing.<\/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>Conduct structured manual testing on priority user journeys (authentication, onboarding, checkout, dashboards, reporting flows).<\/li>\n<li>Participate in sprint rituals: refinement, sprint planning, and (where helpful) demos to confirm accessibility acceptance criteria are met.<\/li>\n<li>Maintain the accessibility backlog: validate statuses, update remediation progress, remove duplicates, clarify reproduction steps.<\/li>\n<li>Host or contribute to a recurring <strong>Accessibility Guild<\/strong> or community-of-practice session.<\/li>\n<li>Provide targeted micro-trainings (15\u201330 minutes) tied to recurring defects (e.g., \u201cAccessible error handling in forms\u201d).<\/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>Perform deeper audits of major modules or new releases; produce audit reports with themes and systemic recommendations.<\/li>\n<li>Review and update accessibility standards documentation to reflect platform changes (design system updates, framework upgrades, new components).<\/li>\n<li>Analyze trends in defect patterns: top recurring issues, components causing failures, teams requiring enablement.<\/li>\n<li>Conduct a quarterly accessibility risk review with Experience Engineering leadership and product governance (scope, compliance posture, top risks, mitigations).<\/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>Design system working group (weekly\/biweekly): align on component accessibility behaviors and documentation.<\/li>\n<li>Product triage meeting (weekly): prioritize cross-team accessibility items and confirm ownership.<\/li>\n<li>UX\/design critiques (weekly): add accessibility lens early, before build.<\/li>\n<li>Engineering PR review rotation (as needed): focus on UI patterns and component usage.<\/li>\n<li>Compliance\/procurement sync (monthly\/quarterly): align on customer requests (VPAT, accessibility statements, contract language).<\/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 regressions discovered late in release cycles or reported by enterprise customers.<\/li>\n<li>Support time-bound customer procurement reviews requiring evidence (e.g., accessibility conformance reporting) under tight deadlines.<\/li>\n<li>Assist with communications when an accessibility issue becomes reputationally sensitive (coordinating with Legal\/Comms per company policy).<\/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 audit reports<\/strong> (module-level, journey-level, or release-level) including findings, severity, impacted users, and remediation guidance.<\/li>\n<li><strong>Remediation backlog<\/strong> with standardized ticket templates: reproduction steps, expected behavior, actual behavior, acceptance criteria, and test steps.<\/li>\n<li><strong>Accessibility acceptance criteria library<\/strong> (for common UI patterns: forms, modals, navigation, tables, charts, toasts, infinite scroll).<\/li>\n<li><strong>Design system accessibility documentation<\/strong>: component behavior specs (keyboard interaction, focus order, ARIA attributes), dos\/don\u2019ts, examples.<\/li>\n<li><strong>Automated testing guidance<\/strong> for accessibility checks in CI\/CD, including what to test, thresholds, and exceptions processes.<\/li>\n<li><strong>Manual testing protocols<\/strong> for keyboard testing, screen reader smoke tests, zoom\/reflow testing, color contrast verification, motion\/reduced motion testing.<\/li>\n<li><strong>Training materials<\/strong>: slide decks, recorded sessions, short \u201chow-to\u201d guides, checklists for designers\/engineers\/QA.<\/li>\n<li><strong>Accessibility KPIs dashboard<\/strong> (or monthly report) tracking defect volume, severity, remediation cycle time, and release readiness.<\/li>\n<li><strong>Accessibility statement input<\/strong> (where published) and supporting evidence, aligned with Legal\/Compliance.<\/li>\n<li><strong>Procurement support artifacts<\/strong>: guidance for evaluating third-party tools; review notes on VPATs and vendor claims (context-specific).<\/li>\n<li><strong>Release readiness sign-off inputs<\/strong>: documented risks and known issues with mitigations (not a formal \u201ccertification\u201d unless the org defines it).<\/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<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Learn product architecture, UI frameworks, design system maturity, and release cadence.<\/li>\n<li>Inventory current accessibility posture:<\/li>\n<li>Existing standards (if any), known high-risk areas, tooling, backlog health, and recurring defects.<\/li>\n<li>Establish working relationships with:<\/li>\n<li>Design system lead, key front-end leads, QA lead, product owners for top user journeys.<\/li>\n<li>Deliver 1\u20132 quick wins:<\/li>\n<li>Fix\/enable one high-impact component issue (e.g., modal focus management) or add a practical checklist to PR templates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">60-day goals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run baseline audits for 1\u20132 critical journeys and produce remediation plans with owners and timelines.<\/li>\n<li>Implement or improve accessibility ticketing templates and severity rubric.<\/li>\n<li>Pilot an accessibility testing workflow:<\/li>\n<li>Add an agreed automated check to CI (where feasible) and define the manual testing complement.<\/li>\n<li>Deliver at least one role-specific training:<\/li>\n<li>Example: \u201cAccessible Forms &amp; Error Handling for React\u201d or \u201cAccessible Navigation Patterns for Designers.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">90-day goals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Establish a repeatable accessibility process in the SDLC:<\/li>\n<li>Definition of done, acceptance criteria, and a practical review cadence.<\/li>\n<li>Align with leadership on accessibility targets (scope + level) and publish internal guidance.<\/li>\n<li>Demonstrate measurable improvements:<\/li>\n<li>Reduced recurrence of top defect category or improved compliance of design system components.<\/li>\n<li>Formalize collaboration model:<\/li>\n<li>Office hours, guild meetings, audit schedule, and escalation pathways.<\/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>Accessibility standards operationalized across multiple teams:<\/li>\n<li>At least 60\u201380% of new UI work uses accessible design system components by default (target varies by maturity).<\/li>\n<li>Accessibility defect leakage reduced:<\/li>\n<li>Fewer high-severity issues found post-release; faster remediation on high-impact defects.<\/li>\n<li>Institutionalize training:<\/li>\n<li>Onboarding module for new designers\/engineers; repeatable curriculum and recordings.<\/li>\n<li>Create credible evidence package:<\/li>\n<li>Audit summaries, known issues register, and customer-ready posture statements (as defined by Legal\/Compliance).<\/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>Achieve consistent conformance on critical journeys to the agreed target (commonly WCAG 2.1\/2.2 AA for web, platform standards for mobile).<\/li>\n<li>Mature the design system:<\/li>\n<li>All core components documented with keyboard interactions, ARIA guidance, and testing notes.<\/li>\n<li>Establish an accessibility operating model:<\/li>\n<li>Clear roles (who tests what), tooling baseline, release gates, and continuous improvement loop.<\/li>\n<li>Improve customer outcomes:<\/li>\n<li>Reduced accessibility-related support tickets; improved satisfaction among users relying on assistive technology.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Long-term impact goals (12\u201324+ months)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility becomes \u201chow we build,\u201d not a separate track:<\/li>\n<li>Teams prevent issues through reusable patterns and automated checks.<\/li>\n<li>Increased enterprise deal velocity in accessibility-sensitive segments.<\/li>\n<li>Reduced total cost of ownership for UI due to fewer retrofits and regressions.<\/li>\n<li>Improved inclusivity and usability across the product, supporting broader UX excellence.<\/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 is embedded in design and engineering workflows, measurable accessibility quality improves release over release, and the organization can confidently demonstrate accessibility posture to customers and regulators (when applicable).<\/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>Finds root causes and shifts work \u201cleft\u201d (design system, patterns, acceptance criteria) rather than only reporting defects.<\/li>\n<li>Communicates in actionable, developer-friendly terms with minimal ambiguity.<\/li>\n<li>Builds trust through pragmatism: recommends fixes that are correct, testable, and feasible.<\/li>\n<li>Improves accessibility outcomes without materially slowing delivery\u2014by enabling teams and reducing rework.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7) KPIs and Productivity Metrics<\/h2>\n\n\n\n<p>The measurement approach should balance <strong>output<\/strong> (what was produced), <strong>outcome<\/strong> (user and business impact), and <strong>quality<\/strong> (conformance and defect rates). Targets vary by product maturity; benchmarks below are illustrative and should be calibrated.<\/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 of critical journeys<\/td>\n<td>% of top journeys audited within the last N months<\/td>\n<td>Ensures risk visibility where it matters most<\/td>\n<td>90% of top 10 journeys audited in last 6 months<\/td>\n<td>Monthly\/Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Accessibility defect discovery stage<\/td>\n<td>Where issues are found (design, dev, QA, prod)<\/td>\n<td>Earlier discovery lowers cost and risk<\/td>\n<td>&gt;70% found pre-QA (design\/dev)<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>High-severity defect leakage<\/td>\n<td># of Sev1\/Sev2 accessibility issues found in production<\/td>\n<td>Measures real customer impact and risk<\/td>\n<td>Trend toward 0; strict cap per release<\/td>\n<td>Per release \/ Monthly<\/td>\n<\/tr>\n<tr>\n<td>Mean time to remediate (MTTR) \u2013 high severity<\/td>\n<td>Average time to fix Sev1\/Sev2 accessibility issues<\/td>\n<td>Drives accountability and reduces harm<\/td>\n<td>Sev1 &lt; 7 days; Sev2 &lt; 30 days (example)<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Recurrence rate of known patterns<\/td>\n<td>Repeat occurrences of the same defect class<\/td>\n<td>Indicates systemic fixes vs whack-a-mole<\/td>\n<td>Reduce top 3 recurring patterns by 50% YoY<\/td>\n<td>Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Design system accessible adoption rate<\/td>\n<td>% of UI built using approved accessible components<\/td>\n<td>Drives scalable accessibility<\/td>\n<td>70\u201390% of new UI uses design system components<\/td>\n<td>Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Automated accessibility checks coverage<\/td>\n<td>% of repos\/pipelines with agreed a11y checks<\/td>\n<td>Improves consistency and regression prevention<\/td>\n<td>60%+ in year 1; higher with maturity<\/td>\n<td>Quarterly<\/td>\n<\/tr>\n<tr>\n<td>False-positive rate in automated checks<\/td>\n<td>Noise level of automated tooling<\/td>\n<td>Tooling must be trusted to be used<\/td>\n<td>&lt;15% false positives on key rules<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Accessibility training completion<\/td>\n<td>% of target audiences completing training<\/td>\n<td>Builds capability across teams<\/td>\n<td>80% of designers\/FE engineers annually<\/td>\n<td>Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Training effectiveness (defect reduction)<\/td>\n<td>Change in defect rate after training<\/td>\n<td>Measures enablement impact<\/td>\n<td>20\u201330% reduction in targeted defect category<\/td>\n<td>Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Stakeholder satisfaction score<\/td>\n<td>Qualitative score from Product\/Eng\/Design partners<\/td>\n<td>Ensures the function is usable and trusted<\/td>\n<td>\u22654.2\/5 internal survey score<\/td>\n<td>Quarterly<\/td>\n<\/tr>\n<tr>\n<td>Customer accessibility tickets<\/td>\n<td># and severity of accessibility-related support cases<\/td>\n<td>Direct signal of user impact<\/td>\n<td>Downward trend; response SLA met<\/td>\n<td>Monthly<\/td>\n<\/tr>\n<tr>\n<td>Accessibility review SLA<\/td>\n<td>Time to respond to review requests<\/td>\n<td>Maintains delivery flow<\/td>\n<td>1\u20132 business days for standard reviews<\/td>\n<td>Weekly\/Monthly<\/td>\n<\/tr>\n<tr>\n<td>Compliance evidence readiness<\/td>\n<td>Ability to produce required documentation quickly<\/td>\n<td>Supports procurement and risk management<\/td>\n<td>Evidence package ready within 5\u201310 days<\/td>\n<td>Quarterly \/ As needed<\/td>\n<\/tr>\n<tr>\n<td>Release readiness risk rating<\/td>\n<td># of releases with unresolved high-risk a11y issues<\/td>\n<td>Prevents shipping critical barriers<\/td>\n<td>0 releases with unmitigated Sev1 barriers<\/td>\n<td>Per release<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<p>Notes on measurement:\n&#8211; Avoid incentivizing \u201cmore defects found\u201d without context; pair defect counts with <strong>stage of discovery<\/strong> and <strong>recurrence reduction<\/strong>.\n&#8211; Automated scores (e.g., Lighthouse) are directional; do not treat them as proof of compliance.\n&#8211; Establish a shared severity rubric (impact + frequency + user segment affected + workaround availability).<\/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 conformance knowledge (2.1\/2.2)<\/strong>\n   &#8211; <strong>Description:<\/strong> Understand success criteria, intent, and common failures.\n   &#8211; <strong>Use:<\/strong> Audit findings, acceptance criteria, remediation guidance.\n   &#8211; <strong>Importance:<\/strong> Critical<\/p>\n<\/li>\n<li>\n<p><strong>Semantic HTML and accessible web patterns<\/strong>\n   &#8211; <strong>Description:<\/strong> Proper headings, landmarks, form controls, tables, link\/button semantics.\n   &#8211; <strong>Use:<\/strong> Implementation guidance and PR\/design reviews.\n   &#8211; <strong>Importance:<\/strong> Critical<\/p>\n<\/li>\n<li>\n<p><strong>ARIA fundamentals (and when not to use ARIA)<\/strong>\n   &#8211; <strong>Description:<\/strong> Roles\/states\/properties, labeling patterns, live regions, common pitfalls.\n   &#8211; <strong>Use:<\/strong> Fixing complex components (menus, dialogs, comboboxes) and diagnosing AT behavior.\n   &#8211; <strong>Importance:<\/strong> Critical<\/p>\n<\/li>\n<li>\n<p><strong>Keyboard accessibility and focus management<\/strong>\n   &#8211; <strong>Description:<\/strong> Tab order, roving tabindex, focus traps, visible focus, skip links.\n   &#8211; <strong>Use:<\/strong> Manual testing and component behavior specifications.\n   &#8211; <strong>Importance:<\/strong> Critical<\/p>\n<\/li>\n<li>\n<p><strong>Assistive technology testing (screen readers + browser combinations)<\/strong>\n   &#8211; <strong>Description:<\/strong> Practical competency with NVDA\/JAWS\/VoiceOver + Chrome\/Firefox\/Safari (as applicable).\n   &#8211; <strong>Use:<\/strong> Validate real user experience beyond automated tooling.\n   &#8211; <strong>Importance:<\/strong> Critical<\/p>\n<\/li>\n<li>\n<p><strong>Accessibility testing methods (manual + automated)<\/strong>\n   &#8211; <strong>Description:<\/strong> Understand strengths\/limits of automation; define test coverage.\n   &#8211; <strong>Use:<\/strong> CI\/CD guidance, test plans, and audits.\n   &#8211; <strong>Importance:<\/strong> Critical<\/p>\n<\/li>\n<li>\n<p><strong>Issue reporting and remediation specification<\/strong>\n   &#8211; <strong>Description:<\/strong> Writing clear, reproducible tickets with acceptance criteria.\n   &#8211; <strong>Use:<\/strong> Backlog quality and efficient delivery.\n   &#8211; <strong>Importance:<\/strong> Important<\/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 and modern UI frameworks literacy (e.g., React, Angular, Vue)<\/strong>\n   &#8211; <strong>Description:<\/strong> Read code, understand component architecture, event handling, routing.\n   &#8211; <strong>Use:<\/strong> Debugging and implementation support.\n   &#8211; <strong>Importance:<\/strong> Important<\/p>\n<\/li>\n<li>\n<p><strong>Mobile accessibility knowledge (iOS\/Android)<\/strong>\n   &#8211; <strong>Description:<\/strong> VoiceOver\/TalkBack basics, touch target sizing, rotor navigation, accessibility labels.\n   &#8211; <strong>Use:<\/strong> If the product includes native apps.\n   &#8211; <strong>Importance:<\/strong> Optional (Context-specific)<\/p>\n<\/li>\n<li>\n<p><strong>Design tools accessibility workflow (Figma\/Sketch)<\/strong>\n   &#8211; <strong>Description:<\/strong> Reviewing color contrast, focus states, component variants, annotation.\n   &#8211; <strong>Use:<\/strong> Shift-left accessibility in design.\n   &#8211; <strong>Importance:<\/strong> Important<\/p>\n<\/li>\n<li>\n<p><strong>Color contrast and visual accessibility<\/strong>\n   &#8211; <strong>Description:<\/strong> Contrast ratios, non-text contrast, use of color, motion sensitivity.\n   &#8211; <strong>Use:<\/strong> Design reviews and token system guidance.\n   &#8211; <strong>Importance:<\/strong> Important<\/p>\n<\/li>\n<li>\n<p><strong>Document accessibility basics (PDF\/Office)<\/strong>\n   &#8211; <strong>Description:<\/strong> Tags, reading order, headings, alt text, accessible tables.\n   &#8211; <strong>Use:<\/strong> Customer-facing documentation or exported reports (if applicable).\n   &#8211; <strong>Importance:<\/strong> Optional (Context-specific)<\/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 patterns and ARIA Authoring Practices<\/strong>\n   &#8211; <strong>Description:<\/strong> Implementing and validating menus, comboboxes, grids, trees, tabs, dialogs.\n   &#8211; <strong>Use:<\/strong> Design system component design and hard UI problems.\n   &#8211; <strong>Importance:<\/strong> Important (Critical in component-heavy apps)<\/p>\n<\/li>\n<li>\n<p><strong>Accessibility in data visualization<\/strong>\n   &#8211; <strong>Description:<\/strong> Accessible tables, summaries, keyboard interactions, text alternatives, focusable chart elements.\n   &#8211; <strong>Use:<\/strong> Analytics dashboards and reporting features.\n   &#8211; <strong>Importance:<\/strong> Optional to Important (Context-specific)<\/p>\n<\/li>\n<li>\n<p><strong>End-to-end accessibility automation strategy<\/strong>\n   &#8211; <strong>Description:<\/strong> Practical integration of axe\/playwright\/cypress checks; baselines; flake reduction.\n   &#8211; <strong>Use:<\/strong> Scaling coverage across multiple repos\/teams.\n   &#8211; <strong>Importance:<\/strong> Important<\/p>\n<\/li>\n<li>\n<p><strong>Regulatory mapping and conformance reporting<\/strong>\n   &#8211; <strong>Description:<\/strong> Translate standards to evidence and scope statements (e.g., VPAT inputs).\n   &#8211; <strong>Use:<\/strong> Enterprise procurement and compliance.\n   &#8211; <strong>Importance:<\/strong> Optional to Important (Context-specific)<\/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>\n   &#8211; <strong>Description:<\/strong> Accessible conversational UI patterns, AI summaries with traceability, error states, and control.\n   &#8211; <strong>Use:<\/strong> Products integrating copilots\/assistants.\n   &#8211; <strong>Importance:<\/strong> Optional (Increasingly important)<\/p>\n<\/li>\n<li>\n<p><strong>Accessibility in design tokens and theming at scale<\/strong>\n   &#8211; <strong>Description:<\/strong> Token-based enforcement of contrast and state visibility across themes.\n   &#8211; <strong>Use:<\/strong> Multi-brand or customizable UI platforms.\n   &#8211; <strong>Importance:<\/strong> Important<\/p>\n<\/li>\n<li>\n<p><strong>Automated code remediation assistance<\/strong>\n   &#8211; <strong>Description:<\/strong> Using AI tooling to draft fixes while ensuring correctness and preventing regressions.\n   &#8211; <strong>Use:<\/strong> Speed up remediation cycles.\n   &#8211; <strong>Importance:<\/strong> Optional<\/p>\n<\/li>\n<li>\n<p><strong>Telemetry-informed accessibility<\/strong>\n   &#8211; <strong>Description:<\/strong> Using analytics to detect friction (e.g., keyboard traps inferred from behavior) while respecting privacy.\n   &#8211; <strong>Use:<\/strong> Prioritization and validation at scale.\n   &#8211; <strong>Importance:<\/strong> Optional (Context-specific)<\/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>Pragmatic influencing without authority<\/strong>\n   &#8211; <strong>Why it matters:<\/strong> The role relies on collaboration across Product, Design, and Engineering.\n   &#8211; <strong>Shows up as:<\/strong> Negotiating scope, persuading teams to adopt patterns, aligning on \u201cgood enough vs must fix.\u201d\n   &#8211; <strong>Strong performance looks like:<\/strong> Teams proactively seek guidance; accessibility is adopted without constant escalation.<\/p>\n<\/li>\n<li>\n<p><strong>Clarity in written communication<\/strong>\n   &#8211; <strong>Why it matters:<\/strong> Accessibility findings must be reproducible and testable.\n   &#8211; <strong>Shows up as:<\/strong> Crisp tickets with steps, expected\/actual behavior, user impact, and acceptance criteria.\n   &#8211; <strong>Strong performance looks like:<\/strong> Engineers can implement fixes without repeated clarification.<\/p>\n<\/li>\n<li>\n<p><strong>Systems thinking<\/strong>\n   &#8211; <strong>Why it matters:<\/strong> The highest ROI comes from fixing root causes (design system, patterns) rather than individual bugs.\n   &#8211; <strong>Shows up as:<\/strong> Identifying recurring defect categories and addressing them via components, standards, and training.\n   &#8211; <strong>Strong performance looks like:<\/strong> Measurable reduction in repeat issues and lower long-term maintenance cost.<\/p>\n<\/li>\n<li>\n<p><strong>User empathy and inclusive mindset<\/strong>\n   &#8211; <strong>Why it matters:<\/strong> Accessibility is ultimately about real people using assistive technology in diverse contexts.\n   &#8211; <strong>Shows up as:<\/strong> Describing impact in user terms; pushing for usability improvements beyond minimal compliance.\n   &#8211; <strong>Strong performance looks like:<\/strong> Recommendations improve the experience, not just pass a checklist.<\/p>\n<\/li>\n<li>\n<p><strong>Constructive conflict management<\/strong>\n   &#8211; <strong>Why it matters:<\/strong> Accessibility can create friction when deadlines are tight.\n   &#8211; <strong>Shows up as:<\/strong> Calmly presenting risk, options, and trade-offs; escalating only when necessary.\n   &#8211; <strong>Strong performance looks like:<\/strong> Resolution paths are clear; relationships remain strong even during crunch time.<\/p>\n<\/li>\n<li>\n<p><strong>Coaching and enablement<\/strong>\n   &#8211; <strong>Why it matters:<\/strong> Scaling accessibility requires capability-building across teams.\n   &#8211; <strong>Shows up as:<\/strong> Training sessions, office hours, pairing with engineers on tricky components.\n   &#8211; <strong>Strong performance looks like:<\/strong> Teams independently apply patterns; fewer \u201cbasic\u201d questions over time.<\/p>\n<\/li>\n<li>\n<p><strong>Attention to detail<\/strong>\n   &#8211; <strong>Why it matters:<\/strong> Small implementation details (labels, roles, focus order) can break accessibility.\n   &#8211; <strong>Shows up as:<\/strong> Catching subtle regressions; verifying across AT\/browser combinations.\n   &#8211; <strong>Strong performance looks like:<\/strong> Low defect leakage and high trust in review outcomes.<\/p>\n<\/li>\n<li>\n<p><strong>Prioritization and risk-based decision-making<\/strong>\n   &#8211; <strong>Why it matters:<\/strong> Not everything can be fixed immediately; effort must match user\/business impact.\n   &#8211; <strong>Shows up as:<\/strong> Severity frameworks, phased remediation, focusing on critical journeys.\n   &#8211; <strong>Strong performance looks like:<\/strong> Backlog is manageable; leadership understands and supports priorities.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">10) Tools, Platforms, and Software<\/h2>\n\n\n\n<p>Tools vary by stack; the list below focuses on what an Accessibility Specialist commonly uses in Experience Engineering.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Category<\/th>\n<th>Tool \/ platform<\/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 (browser)<\/td>\n<td>axe DevTools (Deque)<\/td>\n<td>Manual guided testing and issue details<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (browser)<\/td>\n<td>WAVE Evaluation Tool<\/td>\n<td>Quick checks and visual highlights<\/td>\n<td>Optional<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (browser)<\/td>\n<td>Lighthouse<\/td>\n<td>Baseline automated checks and reporting<\/td>\n<td>Common (as directional)<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (CI)<\/td>\n<td>axe-core (via Jest\/Cypress\/Playwright integrations)<\/td>\n<td>Automated checks in unit\/integration\/E2E<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (CI)<\/td>\n<td>Pa11y<\/td>\n<td>CLI-based scanning and regression checks<\/td>\n<td>Optional<\/td>\n<\/tr>\n<tr>\n<td>Accessibility testing (CI)<\/td>\n<td>ESLint plugins (jsx-a11y)<\/td>\n<td>Prevent common accessibility anti-patterns<\/td>\n<td>Common (web apps)<\/td>\n<\/tr>\n<tr>\n<td>Assistive technology<\/td>\n<td>NVDA (Windows)<\/td>\n<td>Screen reader testing<\/td>\n<td>Common (web)<\/td>\n<\/tr>\n<tr>\n<td>Assistive technology<\/td>\n<td>JAWS (Windows)<\/td>\n<td>Screen reader testing (enterprise-heavy)<\/td>\n<td>Optional (license-dependent)<\/td>\n<\/tr>\n<tr>\n<td>Assistive technology<\/td>\n<td>VoiceOver (macOS\/iOS)<\/td>\n<td>Screen reader testing for Apple ecosystem<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Assistive technology<\/td>\n<td>TalkBack (Android)<\/td>\n<td>Screen reader testing for Android apps<\/td>\n<td>Context-specific<\/td>\n<\/tr>\n<tr>\n<td>Design<\/td>\n<td>Figma<\/td>\n<td>Design review and component specs<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Dev collaboration<\/td>\n<td>GitHub \/ GitLab<\/td>\n<td>PR reviews, code navigation, issues<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Issue tracking<\/td>\n<td>Jira \/ Azure DevOps<\/td>\n<td>Backlog management and ticketing<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Documentation<\/td>\n<td>Confluence \/ Notion<\/td>\n<td>Standards, guidelines, audit reports<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Analytics (basic)<\/td>\n<td>Looker \/ Power BI<\/td>\n<td>KPI dashboards and trend analysis<\/td>\n<td>Optional<\/td>\n<\/tr>\n<tr>\n<td>Communication<\/td>\n<td>Slack \/ Microsoft Teams<\/td>\n<td>Office hours, triage, stakeholder comms<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Browser dev tools<\/td>\n<td>Chrome DevTools \/ Firefox DevTools<\/td>\n<td>Inspect accessibility tree, ARIA, contrast<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Color\/visual checks<\/td>\n<td>Contrast checkers (e.g., Stark, Colour Contrast Analyser)<\/td>\n<td>Contrast validation and design feedback<\/td>\n<td>Common<\/td>\n<\/tr>\n<tr>\n<td>Prototyping (optional)<\/td>\n<td>Storybook<\/td>\n<td>Component review and documentation<\/td>\n<td>Context-specific (design system orgs)<\/td>\n<\/tr>\n<tr>\n<td>QA testing<\/td>\n<td>BrowserStack \/ Sauce Labs<\/td>\n<td>Cross-browser verification<\/td>\n<td>Optional<\/td>\n<\/tr>\n<tr>\n<td>Mobile dev tools<\/td>\n<td>Xcode Accessibility Inspector<\/td>\n<td>iOS testing and debugging<\/td>\n<td>Context-specific<\/td>\n<\/tr>\n<tr>\n<td>Mobile dev tools<\/td>\n<td>Android Studio Accessibility Scanner<\/td>\n<td>Android testing<\/td>\n<td>Context-specific<\/td>\n<\/tr>\n<tr>\n<td>Standards references<\/td>\n<td>WCAG quick reference \/ ARIA Authoring Practices<\/td>\n<td>Guidance for patterns and interpretation<\/td>\n<td>Common<\/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<h3 class=\"wp-block-heading\">Infrastructure environment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primarily relevant indirectly; the role usually operates at the <strong>application layer<\/strong> rather than infrastructure.<\/li>\n<li>In larger orgs, accessibility tooling may run in shared CI environments (cloud-hosted runners) with permissions managed by DevOps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Application environment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Web applications built with modern frameworks (commonly <strong>React<\/strong>, but could be Angular\/Vue).<\/li>\n<li>Component-based architecture with a design system or UI library.<\/li>\n<li>Common UI patterns: complex tables, filters, charts, modals, wizards, and settings screens.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Data environment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility work generally does not require deep data engineering, but may rely on:<\/li>\n<li>Analytics to prioritize high-traffic journeys.<\/li>\n<li>Defect tracking data (Jira\/Azure DevOps) for trends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security environment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility tooling must comply with security policies:<\/li>\n<li>Browser extensions may require approval.<\/li>\n<li>Audit tooling might require access to staging environments with test data.<\/li>\n<li>When capturing evidence, follow data handling guidelines (avoid sensitive user data in screenshots or logs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Delivery model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Agile delivery with sprints; continuous delivery in mature orgs.<\/li>\n<li>Accessibility integrated into:<\/li>\n<li>Discovery\/design phase (shift-left).<\/li>\n<li>Development (linting, component usage).<\/li>\n<li>QA (manual AT smoke tests).<\/li>\n<li>Release readiness (risk review and exception process).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Agile or SDLC context<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility acceptance criteria embedded in user stories.<\/li>\n<li>Definition of done includes accessibility checks appropriate to story type (UI vs backend).<\/li>\n<li>Release gates may include:<\/li>\n<li>No open Sev1 accessibility issues for critical journeys.<\/li>\n<li>A documented exception process for non-blocking issues.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scale or complexity context<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Complexity increases with:<\/li>\n<li>Many teams contributing UI.<\/li>\n<li>Custom components and legacy patterns.<\/li>\n<li>Multiple brands\/themes and localization.<\/li>\n<li>Enterprise customer requirements and procurement scrutiny.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team topology<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Accessibility Specialist typically sits in <strong>Experience Engineering<\/strong>:<\/li>\n<li>Works as a shared specialist across multiple product squads.<\/li>\n<li>Close partnership with Design Systems, QA, and Front-End platform teams.<\/li>\n<li>In larger orgs, may be part of a small <strong>Accessibility COE<\/strong> (center of excellence) while embedded part-time with squads.<\/li>\n<\/ul>\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 (manager\/reporting line):<\/strong><\/li>\n<li>Sets priorities, resolves cross-team conflicts, funds tooling\/training.<\/li>\n<li><strong>Design System Lead \/ UX Engineering Lead:<\/strong><\/li>\n<li>Primary partner for scalable fixes (components and patterns).<\/li>\n<li><strong>Product Managers (core journeys):<\/strong><\/li>\n<li>Prioritization, scope decisions, customer commitments.<\/li>\n<li><strong>UX\/UI Designers:<\/strong><\/li>\n<li>Shift-left reviews: interaction patterns, focus states, layouts, contrast, content structure.<\/li>\n<li><strong>Front-End Engineers:<\/strong><\/li>\n<li>Implementation of fixes, PR collaboration, component adoption.<\/li>\n<li><strong>Mobile Engineers (if applicable):<\/strong><\/li>\n<li>Platform-specific accessibility patterns and testing.<\/li>\n<li><strong>QA\/Test Engineers:<\/strong><\/li>\n<li>Test strategy alignment, regression coverage, release readiness checks.<\/li>\n<li><strong>UX Researchers:<\/strong><\/li>\n<li>Inclusive research planning, validation with assistive tech users.<\/li>\n<li><strong>Legal\/Compliance \/ GRC (context-specific):<\/strong><\/li>\n<li>Regulatory interpretation, risk posture, external statements.<\/li>\n<li><strong>Customer Support\/Success:<\/strong><\/li>\n<li>Ticket intake and escalation; customer communication and workarounds.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">External stakeholders (when applicable)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Enterprise customers\/prospects:<\/strong><\/li>\n<li>Accessibility questionnaires, procurement requirements, audit evidence requests.<\/li>\n<li><strong>Third-party vendors:<\/strong><\/li>\n<li>Accessibility posture and documentation (VPATs, audit reports).<\/li>\n<li><strong>External auditors\/consultants (optional):<\/strong><\/li>\n<li>Independent evaluations; validation for high-stakes contracts.<\/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 \/ UI Platform Engineer<\/li>\n<li>UX Designer \/ Product Designer<\/li>\n<li>QA Lead \/ SDET<\/li>\n<li>Content Designer \/ Technical Writer<\/li>\n<li>Security\/GRC Analyst (for governance alignment)<\/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>Product requirements and prioritization decisions.<\/li>\n<li>Design system roadmap and engineering capacity.<\/li>\n<li>CI\/CD and developer tooling support for automation.<\/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 implementing fixes and patterns.<\/li>\n<li>QA teams running testing protocols.<\/li>\n<li>Customer-facing teams needing credible statements and evidence.<\/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><strong>Advisory + enablement:<\/strong> Provide guidance and training that teams can reuse.<\/li>\n<li><strong>Hands-on validation:<\/strong> Audit, test, and verify critical flows.<\/li>\n<li><strong>Shared ownership:<\/strong> Accessibility outcomes are owned by product teams; the specialist ensures standards, visibility, and capability.<\/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>Recommends severity, prioritization inputs, and standards interpretations.<\/li>\n<li>Can block or escalate high-risk accessibility barriers based on defined release policy (varies by org).<\/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>To Experience Engineering leader for unresolved disputes, resourcing issues, or policy enforcement.<\/li>\n<li>To Product leadership for scope exceptions that create user harm or compliance risk.<\/li>\n<li>To Legal\/Compliance for external commitments, regulatory interpretation, or customer-facing statements.<\/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\">Decisions this role can make independently<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Severity classification using the agreed rubric (with transparency).<\/li>\n<li>Audit scope and testing approach for assigned modules\/journeys.<\/li>\n<li>Recommended remediation approach and acceptance criteria for typical UI issues.<\/li>\n<li>Training content and enablement plans for common accessibility patterns.<\/li>\n<li>Tool usage within approved security constraints (e.g., selecting which checks to run and when).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Decisions requiring team approval (Product\/Design\/Engineering)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prioritization of remediation work within sprint\/roadmap planning.<\/li>\n<li>Design changes that affect UX patterns (navigation structure, component behavior).<\/li>\n<li>Engineering approach that impacts architecture (component refactors, framework-level changes).<\/li>\n<li>Updates to shared design system components and APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Decisions requiring manager\/director\/executive approval<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Formal accessibility policy commitments (target WCAG level, public claims).<\/li>\n<li>Release gating policy changes (e.g., \u201cno Sev1 issues can ship\u201d enforcement).<\/li>\n<li>Budget for paid tools (e.g., Deque licenses, JAWS licenses) and external audits.<\/li>\n<li>Vendor selection decisions when accessibility is a contractual requirement.<\/li>\n<li>Hiring decisions for additional accessibility roles or establishing a COE.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Budget, vendor, delivery, hiring, or compliance authority<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Budget:<\/strong> Typically influences through recommendations; does not own budget.<\/li>\n<li><strong>Vendor:<\/strong> Provides evaluation input; final decisions are usually Procurement + leadership.<\/li>\n<li><strong>Delivery:<\/strong> Can recommend go\/no-go from an accessibility risk perspective where policy exists.<\/li>\n<li><strong>Hiring:<\/strong> May participate in interviews for UX engineering, front-end, QA, and design system roles.<\/li>\n<li><strong>Compliance:<\/strong> Supports evidence and mapping; Legal\/Compliance owns formal regulatory positions.<\/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>Commonly <strong>3\u20136 years<\/strong> in accessibility-focused work or an adjacent discipline (front-end engineering, QA, UX) with demonstrated accessibility depth.<\/li>\n<li>In some orgs, a strong candidate may have fewer years but substantial hands-on portfolio evidence.<\/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 is often preferred (HCI, Computer Science, Design, Information Systems), but not strictly required if experience demonstrates proficiency.<\/li>\n<li>Equivalent experience through hands-on work and recognized contributions is acceptable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certifications (optional; not strictly required)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAAP CPACC<\/strong> (Common; credibility for foundational knowledge)<\/li>\n<li><strong>IAAP WAS<\/strong> (Optional; deeper web specialization)<\/li>\n<li><strong>Deque University certificates<\/strong> (Optional; tool\/vendor specific)<\/li>\n<li>Any certification should be treated as supportive evidence, not a substitute for practical skill.<\/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>Front-End Developer \/ UI Engineer with accessibility focus<\/li>\n<li>QA Engineer \/ SDET who specialized in accessibility testing<\/li>\n<li>UX Designer \/ UX Engineer with strong accessibility practice<\/li>\n<li>Content Designer \/ Technical Writer with accessibility expertise (less common, but viable)<\/li>\n<li>Digital compliance analyst (in regulated environments)<\/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>Software product delivery lifecycle (agile).<\/li>\n<li>Design systems and component-based development.<\/li>\n<li>Basic understanding of procurement\/compliance needs in enterprise SaaS (context-specific).<\/li>\n<li>Understanding of inclusive design principles and usability beyond compliance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Leadership experience expectations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not a people-manager role.<\/li>\n<li>Expected to lead through influence:<\/li>\n<li>Facilitate cross-team remediation efforts.<\/li>\n<li>Run training and working sessions.<\/li>\n<li>Drive adoption of patterns and standards.<\/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>Front-End Engineer \u2192 Accessibility Specialist<\/li>\n<li>QA Engineer\/SDET \u2192 Accessibility Specialist<\/li>\n<li>UX Engineer \/ Design System Engineer \u2192 Accessibility Specialist<\/li>\n<li>Product Designer (with strong accessibility depth) \u2192 Accessibility Specialist<\/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>Senior Accessibility Specialist<\/strong><\/li>\n<li><strong>Accessibility Lead \/ Accessibility Program Manager<\/strong> (if the org creates a program\/COE track)<\/li>\n<li><strong>Design System Accessibility Lead<\/strong><\/li>\n<li><strong>UX Engineering Lead<\/strong> (with accessibility as a key quality dimension)<\/li>\n<li><strong>Inclusive Design Lead<\/strong> (broader than standards conformance)<\/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><strong>UX Research (specializing in disability inclusion)<\/strong><\/li>\n<li><strong>Product Quality \/ QA leadership<\/strong><\/li>\n<li><strong>GRC\/Compliance specializing in digital accessibility<\/strong> (more common in regulated industries)<\/li>\n<li><strong>Developer Experience (DevEx)<\/strong> focusing on linting\/testing standards, with accessibility as a pillar<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Skills needed for promotion (to Senior or Lead)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Demonstrated ability to drive measurable accessibility improvements across multiple teams.<\/li>\n<li>Advanced mastery of complex widget patterns and design system governance.<\/li>\n<li>Ability to define an operating model: tooling strategy, training curriculum, release gates, exception handling.<\/li>\n<li>Strong stakeholder management: aligning Product\/Eng\/Legal on commitments and evidence.<\/li>\n<li>Mentoring others (even without direct reports) and building scalable enablement assets.<\/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: audit + triage + build trust + deliver quick wins.<\/li>\n<li>Mid phase: standardize patterns, integrate checks into pipelines, mature design system accessibility.<\/li>\n<li>Mature phase: programmatic governance, metrics-driven improvement, external evidence readiness, and coaching a network of accessibility champions.<\/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:<\/strong> Accessibility issues found near release, causing schedule tension and incomplete fixes.<\/li>\n<li><strong>Ambiguous ownership:<\/strong> Teams treat accessibility as \u201csomeone else\u2019s job,\u201d slowing remediation.<\/li>\n<li><strong>Over-reliance on automation:<\/strong> Teams assume automated tools prove compliance; manual issues remain.<\/li>\n<li><strong>Legacy UI and tech debt:<\/strong> Fixing deep component issues requires coordination and time.<\/li>\n<li><strong>Tooling friction:<\/strong> CI checks can be noisy; false positives reduce trust and adoption.<\/li>\n<li><strong>Competing priorities:<\/strong> Product deadlines vs accessibility remediation without clear governance.<\/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 capacity to implement shared fixes.<\/li>\n<li>Limited QA capacity for manual AT testing.<\/li>\n<li>Specialist becomes a single point of failure (review bottleneck) without champion model and self-service tools.<\/li>\n<li>Lack of consistent acceptance criteria leads to repeated debate and inconsistent fixes.<\/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 final QA pass\u201d instead of designing\/building accessibly.<\/li>\n<li>Shipping exceptions without documentation or mitigation plans.<\/li>\n<li>Treating WCAG as a checklist rather than focusing on user impact and real AT behavior.<\/li>\n<li>Adding ARIA everywhere (\u201cARIA as a band-aid\u201d) rather than using semantic HTML.<\/li>\n<li>Measuring success solely by tool scores rather than journey usability and defect leakage.<\/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>Provides findings without actionable guidance (tickets unclear, recommendations impractical).<\/li>\n<li>Lacks credibility with engineers (doesn\u2019t understand component architecture or feasible fixes).<\/li>\n<li>Becomes adversarial rather than collaborative, creating resistance.<\/li>\n<li>Fails to prioritize; spends too much time on low-impact pages while critical journeys remain risky.<\/li>\n<li>Doesn\u2019t build scalable assets (standards, components, automation), leading to repeated manual effort.<\/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>Increased legal and contractual risk, especially in public sector and enterprise procurement.<\/li>\n<li>Lost deals due to inability to provide credible accessibility evidence.<\/li>\n<li>Higher support costs and reputational harm from users unable to complete critical tasks.<\/li>\n<li>Increased engineering cost due to late-stage retrofits and regressions.<\/li>\n<li>Lower product quality perception and reduced customer satisfaction.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">17) Role Variants<\/h2>\n\n\n\n<p>Accessibility Specialist scope changes significantly by organization context. The core discipline remains the same, but emphasis shifts.<\/p>\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 product org<\/strong><\/li>\n<li>More hands-on implementation guidance; may contribute directly to code fixes.<\/li>\n<li>Less formal governance; relies on lightweight standards and fast enablement.<\/li>\n<li><strong>Mid-size scale-up<\/strong><\/li>\n<li>Strong focus on design system, repeatable processes, CI checks, and training.<\/li>\n<li>Balances audits with building an accessibility champion network.<\/li>\n<li><strong>Enterprise<\/strong><\/li>\n<li>Heavier governance, documentation, reporting, and procurement support.<\/li>\n<li>More stakeholder complexity (Legal, Compliance, multiple product lines).<\/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><\/li>\n<li>Strong compliance requirements; evidence readiness is critical.<\/li>\n<li><strong>Fintech \/ healthcare<\/strong><\/li>\n<li>Higher risk tolerance is low; rigorous process and documentation.<\/li>\n<li><strong>B2B SaaS (general)<\/strong><\/li>\n<li>Mix of usability and procurement-driven compliance; focus on critical workflows and VPAT-like needs (context-specific).<\/li>\n<li><strong>Consumer apps<\/strong><\/li>\n<li>Strong emphasis on scale, experimentation, and mobile accessibility.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">By geography (high-level, non-exhaustive)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>United States<\/strong><\/li>\n<li>ADA-related litigation risk; Section 508 for federal procurement.<\/li>\n<li><strong>EU<\/strong><\/li>\n<li>EN 301 549 alignment common; increasing regulatory scrutiny.<\/li>\n<li><strong>Canada<\/strong><\/li>\n<li>AODA considerations in certain provinces; procurement requirements.<\/li>\n<li><strong>UK<\/strong><\/li>\n<li>Equality Act context; public sector accessibility expectations.<blockquote>\n<p>The role should not provide legal advice, but must collaborate with Legal\/Compliance to align internal targets and external claims.<\/p>\n<\/blockquote>\n<\/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><\/li>\n<li>Emphasis on design system scalability, regression prevention, and consistent UX patterns.<\/li>\n<li><strong>Service-led \/ IT org delivering for clients<\/strong><\/li>\n<li>More project-based audits, client reporting, and handoffs; may require more formal documentation and sign-offs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup vs enterprise operating model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Startup:<\/strong> \u201cDo and teach\u201d model; fewer gates, more direct collaboration.<\/li>\n<li><strong>Enterprise:<\/strong> Governance and evidence readiness; formal exception processes; more reporting.<\/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, audit trails, vendor review, and release gating.<\/li>\n<li><strong>Non-regulated:<\/strong> More flexibility but still benefits from disciplined process to reduce risk and improve UX.<\/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 significantly accelerated)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Automated scanning and regression detection<\/strong><\/li>\n<li>CI checks for common failures (missing labels, contrast, invalid ARIA, landmark issues).<\/li>\n<li><strong>Drafting ticket content<\/strong><\/li>\n<li>AI-assisted creation of reproduction steps and suggested fixes (must be validated).<\/li>\n<li><strong>Code pattern suggestions<\/strong><\/li>\n<li>IDE copilots can propose accessible markup and ARIA patterns (requires expert review).<\/li>\n<li><strong>Documentation generation<\/strong><\/li>\n<li>Initial drafts of guidelines\/checklists and release notes (must align with policy and standards).<\/li>\n<li><strong>Trend analysis<\/strong><\/li>\n<li>Automated clustering of defect themes from ticket data to identify systemic issues.<\/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>Manual assistive technology testing<\/strong><\/li>\n<li>Real screen reader experience, keyboard interaction nuances, and usability judgment.<\/li>\n<li><strong>Standards interpretation and trade-offs<\/strong><\/li>\n<li>Determining best solutions in ambiguous scenarios; balancing UX intent with conformance.<\/li>\n<li><strong>Stakeholder negotiation<\/strong><\/li>\n<li>Prioritization, release risk decisions, and influencing behavior change.<\/li>\n<li><strong>Design system behavior specification<\/strong><\/li>\n<li>Defining keyboard interactions and component APIs that are both accessible and developer-friendly.<\/li>\n<li><strong>Quality judgment<\/strong><\/li>\n<li>Determining whether a fix truly improves usability vs \u201cpasses a rule.\u201d<\/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 specialist shifts from \u201cmanual checker\u201d to <strong>accessibility quality engineer\/program enabler<\/strong>:<\/li>\n<li>Designing smarter test strategies.<\/li>\n<li>Validating AI-generated fixes.<\/li>\n<li>Improving developer workflows and reducing friction.<\/li>\n<li>Increased expectation to <strong>instrument accessibility quality<\/strong>:<\/li>\n<li>Better integration with QA automation and component pipelines.<\/li>\n<li>More continuous monitoring in pre-prod environments.<\/li>\n<li>More focus on <strong>AI feature accessibility<\/strong>:<\/li>\n<li>Accessible chat interfaces, generated content readability, controllability, and error recovery.<\/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-generated UI\/code for accessibility regressions.<\/li>\n<li>Governance for AI-generated content (e.g., alt text quality, summaries, dynamic updates).<\/li>\n<li>Stronger partnership with DevEx\/platform teams to embed a11y checks into golden paths.<\/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<ol class=\"wp-block-list\">\n<li><strong>Practical WCAG knowledge<\/strong>\n   &#8211; Can the candidate explain key criteria and apply them to real UI scenarios?<\/li>\n<li><strong>Hands-on testing skill<\/strong>\n   &#8211; Can they conduct keyboard and screen reader testing and articulate findings clearly?<\/li>\n<li><strong>Implementation literacy<\/strong>\n   &#8211; Can they propose correct semantic\/ARIA solutions without overusing ARIA?<\/li>\n<li><strong>Ticket quality and remediation guidance<\/strong>\n   &#8211; Can they write actionable issues with acceptance criteria and test steps?<\/li>\n<li><strong>Design collaboration<\/strong>\n   &#8211; Can they identify issues in mockups (contrast, focus states, structure) and suggest fixes that preserve UX?<\/li>\n<li><strong>Program thinking<\/strong>\n   &#8211; Can they scale impact through design systems, automation, and training?<\/li>\n<li><strong>Stakeholder management<\/strong>\n   &#8211; Can they handle conflict, deadlines, and pragmatic trade-offs?<\/li>\n<\/ol>\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><strong>Audit exercise (60\u201390 minutes)<\/strong>\n   &#8211; Provide a simple web page\/app flow (staging URL or static) and ask the candidate to:<ul>\n<li>Identify top accessibility issues.<\/li>\n<li>Prioritize by severity.<\/li>\n<li>Provide 3\u20135 clear remediation recommendations.<\/li>\n<li>Describe how they would verify fixes.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Ticket-writing exercise (30 minutes)<\/strong>\n   &#8211; Candidate writes a Jira-style ticket for one issue including:<ul>\n<li>Steps to reproduce, expected\/actual behavior, user impact, acceptance criteria.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Design review scenario (30\u201345 minutes)<\/strong>\n   &#8211; Review a Figma mock of a modal\/form\/table and ask for accessibility risks and design changes.<\/li>\n<li><strong>Automation strategy discussion (30 minutes)<\/strong>\n   &#8211; Ask how they would combine linting + component tests + E2E checks + manual AT testing.<\/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 mastery of fundamentals: labels, semantics, focus, keyboard, headings, error handling.<\/li>\n<li>Uses assistive technology confidently and can explain what they are observing.<\/li>\n<li>Balances compliance language with user impact (\u201cwho is blocked and why\u201d).<\/li>\n<li>Offers pragmatic solutions aligned with modern UI frameworks and component systems.<\/li>\n<li>Understands limitations of automation and proposes realistic coverage.<\/li>\n<li>Communicates clearly and respectfully; can influence without being adversarial.<\/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>Over-indexes on tool output and cannot explain underlying issues.<\/li>\n<li>Suggests incorrect ARIA usage or uses ARIA as a default solution.<\/li>\n<li>Cannot describe how to test fixes beyond re-running automated scans.<\/li>\n<li>Produces vague recommendations (\u201cmake it accessible\u201d) without acceptance criteria.<\/li>\n<li>Dismisses design constraints or delivery realities without proposing options.<\/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>Claims compliance based solely on Lighthouse\/automated scores.<\/li>\n<li>Provides legal interpretations or guarantees without involving Legal\/Compliance.<\/li>\n<li>Cannot demonstrate any screen reader testing experience for a web-focused product.<\/li>\n<li>Resistant to collaboration (\u201cthe team must do what I say\u201d) and lacks pragmatism.<\/li>\n<li>Suggests hiding content or reducing functionality to \u201csolve\u201d accessibility rather than designing inclusive solutions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scorecard dimensions (interview evaluation)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Dimension<\/th>\n<th>What \u201cmeets bar\u201d looks like<\/th>\n<th>What \u201cexceeds\u201d looks like<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>WCAG &amp; standards application<\/td>\n<td>Correctly maps common issues to relevant criteria and intent<\/td>\n<td>Handles edge cases and explains trade-offs clearly<\/td>\n<\/tr>\n<tr>\n<td>Manual testing capability<\/td>\n<td>Competent keyboard + screen reader smoke tests<\/td>\n<td>Efficient, methodical testing across AT\/browser combos<\/td>\n<\/tr>\n<tr>\n<td>Remediation guidance quality<\/td>\n<td>Actionable fixes and clear acceptance criteria<\/td>\n<td>Provides reusable patterns and anticipates regressions<\/td>\n<\/tr>\n<tr>\n<td>Engineering literacy<\/td>\n<td>Understands component-based UI and semantics<\/td>\n<td>Can read code and propose framework-appropriate solutions<\/td>\n<\/tr>\n<tr>\n<td>Design collaboration<\/td>\n<td>Identifies design risks and suggests improvements<\/td>\n<td>Influences design system patterns and token strategies<\/td>\n<\/tr>\n<tr>\n<td>Automation understanding<\/td>\n<td>Realistic use of automation with limitations<\/td>\n<td>Proposes scalable strategy with low noise and high ROI<\/td>\n<\/tr>\n<tr>\n<td>Stakeholder management<\/td>\n<td>Communicates clearly; prioritizes pragmatically<\/td>\n<td>De-escalates conflict and drives alignment across teams<\/td>\n<\/tr>\n<tr>\n<td>Enablement mindset<\/td>\n<td>Willing to teach and document<\/td>\n<td>Builds scalable training and champion networks<\/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><strong>Role title<\/strong><\/td>\n<td>Accessibility Specialist<\/td>\n<\/tr>\n<tr>\n<td><strong>Role purpose<\/strong><\/td>\n<td>Ensure digital products are usable by people with disabilities by embedding accessibility standards, testing, remediation, and enablement into the product lifecycle.<\/td>\n<\/tr>\n<tr>\n<td><strong>Top 10 responsibilities<\/strong><\/td>\n<td>1) Define accessibility targets with leadership 2) Run audits (manual + automated) 3) Triage and manage a11y backlog 4) Write actionable remediation guidance and acceptance criteria 5) Validate fixes with keyboard\/AT testing 6) Partner with design system on accessible components 7) Integrate accessibility checks into SDLC\/CI where feasible 8) Train and coach designers\/engineers\/QA 9) Support procurement\/customer evidence needs (context-specific) 10) Report metrics and risks to stakeholders<\/td>\n<\/tr>\n<tr>\n<td><strong>Top 10 technical skills<\/strong><\/td>\n<td>1) WCAG 2.1\/2.2 application 2) Semantic HTML 3) ARIA fundamentals + Authoring Practices 4) Keyboard\/focus management 5) Screen reader testing (NVDA\/VoiceOver; JAWS optional) 6) Manual + automated testing strategy 7) Accessibility issue writing (severity, repro, acceptance criteria) 8) Framework literacy (React\/Angular\/Vue) 9) Contrast\/visual accessibility 10) CI-based a11y checks (axe-core integrations, eslint jsx-a11y)<\/td>\n<\/tr>\n<tr>\n<td><strong>Top 10 soft skills<\/strong><\/td>\n<td>1) Influencing without authority 2) Clear writing 3) Systems thinking 4) User empathy 5) Constructive conflict management 6) Coaching\/enablement 7) Attention to detail 8) Risk-based prioritization 9) Cross-functional collaboration 10) Practical problem solving<\/td>\n<\/tr>\n<tr>\n<td><strong>Top tools or platforms<\/strong><\/td>\n<td>axe DevTools, Lighthouse, NVDA, VoiceOver, Contrast checkers (e.g., Stark\/CCA), Chrome\/Firefox DevTools accessibility tree, Jira\/Azure DevOps, GitHub\/GitLab, Figma, Confluence\/Notion<\/td>\n<\/tr>\n<tr>\n<td><strong>Top KPIs<\/strong><\/td>\n<td>High-severity defect leakage, MTTR for high severity, audit coverage of critical journeys, defect discovery stage shift-left, recurrence reduction of top defect patterns, design system adoption rate, automated check coverage and noise levels, stakeholder satisfaction, training completion\/effectiveness, customer ticket trend<\/td>\n<\/tr>\n<tr>\n<td><strong>Main deliverables<\/strong><\/td>\n<td>Audit reports, remediation backlogs and ticket templates, accessibility acceptance criteria library, design system accessibility specs\/documentation, testing protocols, training materials, KPI dashboards\/reports, release risk summaries, procurement evidence inputs (context-specific)<\/td>\n<\/tr>\n<tr>\n<td><strong>Main goals<\/strong><\/td>\n<td>First 90 days: baseline audits + embed acceptance criteria + establish repeatable process; 6\u201312 months: measurable reduction in defects\/leakage, scalable design system accessibility, integrated testing approach, credible evidence readiness<\/td>\n<\/tr>\n<tr>\n<td><strong>Career progression options<\/strong><\/td>\n<td>Senior Accessibility Specialist, Accessibility Lead\/Program Manager, Design System Accessibility Lead, UX Engineering Lead, Inclusive Design Lead, Quality\/Testing leadership, Accessibility-focused GRC\/compliance (context-specific)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n","protected":false},"excerpt":{"rendered":"<p>An **Accessibility Specialist** ensures that digital products and services are usable by people with disabilities and conform to relevant accessibility standards. In a software company or IT organization, this role reduces legal\/compliance risk, expands market reach, improves user experience quality, and enables teams to build accessibility in by default rather than treating it as a late-stage fix.<\/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-75060","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\/75060","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=75060"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/75060\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=75060"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=75060"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=75060"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}