Designers and developers shape the digital experiences people rely on every day. The ARC equips them to build universally accessible products. Both groups will gain a strong shared foundation by using the ARC.
Accessibility Tools
The ARC lets both groups team up, aiming for the same WCAG results, but using different tools. Each criterion affects both professions differently, so the ARC pairs every topic with matching tools for each role. For example:
- Colour contrast: a designer could use a Figma plugin, while a developer may use a code checker. The ARC records both tools in one place (folder, section, title) so teams know exactly how each side confirms compliance.
- The same structure applies to keyboard navigation, screen reader narration and component interactions. Designers use annotation templates to describe the expected focus order and tutor messages. Developers use curated linters, testing scripts and screen reader checklists to validate those expectations in code.
A shared and categorized topic structure removes guesswork and keeps both professions aligned. You can organize your ARC by WCAG groups or the complete list of success criteria.
Communication
The ARC helps designers and developers communicate with clarity and purpose. Designers can annotate wireframes with detailed Accessibility notes using ARC templates. These notes describe expected keyboard interactions, focus order, labels and screen reader tutor messages. Developers review these annotations early and ask questions before writing code. When a component feels unclear, teams should create quick prototypes. That way, everyone can confirm the same behaviour before development begins.
In my experience, the first Accessibility audit often reveals how well this communication worked. A high compliance result usually reflects strong alignment. Low compliance often signals that something broke down along the way. Many teams fall into the trap of assuming developers already know every detail about Assistive Technology (AT).
After 20 years of projects, I still have not met a developer who received formal training on screen reader tutor messages or ARIA attributes. They usually learn these details through hands‑on remediation work. Therefore, teams should never assume or take their Accessibility knowledge for granted.
To avoid misunderstandings, designers should always include AT expectations in their annotations. Confirm that the developers have reviewed the annotations. Confirm no doubts remain after the annotation’s review.
The ARC also records audit‑derived learning so teams can improve with each project.
Design Systems
The ARC helps teams protect quality. Whether they work with a full design system or deliver tailored solutions for individual customers.
A living design system offers clear advantages. When components share the same foundation, every audit benefits all products that rely on those patterns. Designers and developers can agree on bugs and solutions more easily. Regular audits help teams catch drift before it becomes a larger problem.
It’s true that not every company has this luxury. Many teams build custom solutions for each client, which means early detection becomes essential. Here, the ARC should include: component audit checklists, annotation forms and pattern‑library guidance. Designers can document expected behaviour for each component, focus order, and interaction rules. Developers can use these notes to build predictable, consistent experiences. The ARC gives both groups the structure they need to stay aligned, even when every project looks different.
UX Research
UX research grounds Accessibility decisions in real-world user experience. The ARC supplies templates and tools that make research practical and repeatable. Some examples:
- User testing feedback forms tailored for people using assistive technology.
- Accessibility persona validation checklists linked to WCAG success criteria.
- Recruitment guides for inclusive participant outreach and respectful engagement.
- Script templates for moderated and unmoderated Accessibility testing sessions.
- Consent forms and accommodation request templates that respect participant dignity.
- Analysis templates and prioritization matrices tied to remediation workflows.
AI Support
The ARC should include resources that show how to use Artificial intelligence (AI). Designers can easily generate UX personas aligned with WCAG success criteria. Developers can create quick CodePen prototypes and explore ideas for inclusive design. AI helps in the instant production of sample code for accessible navigation patterns or tutor messages. Although it helps teams move faster, it needs careful guidance.
Warning: AI saves time, but it does not replace thoughtful judgment. AI sometimes mislabels user needs or suggests features that do not match real-world disabilities. E.g., AI will tell you with a straight face to consider colour contrast for blind UX personas. I have seen this happening, especially when compounding disabilities for use cases. The ARC must encourage teams to review AI outputs with care. Make sure to compare results across AI models and validate everything with real user insights. This habit protects quality and keeps the work grounded in truth.
Partnerships
Teams should always seek guidance from Certified Professionals in Web Accessibility (CPWA). Their training helps teams interpret WCAG with clarity. Their information should be available on the ARC.
For external Accessibility Auditors, teams should know their methodology and tools. Learn how auditors use screen readers, code inspection and automated scanners. Do they test with testers with real disabilities, or just simulate the use case? Replicate the auditor’s process when you fix issues and produce evidence using the same tools and steps.
Record the auditor’s reputation, tester credentials and testing approach in the ARC. This practice speeds remediation and proves fixes to stakeholders and future team members.
Next article: “ARC: Empowering Sales and Support.” How customer-facing teams use the ARC to communicate accessibility clearly and responsibly.
