Category: Models

Reading Time: 2 minutes

Sales and support teams shape the first and last impressions of any product. Their words guide individuals through choices, concerns, and commitments. The ARC gives these teams a clear path to speak about Accessibility with confidence and accuracy.

Sales Teams

Sales teams help people understand how a product supports their needs. The ARC gives them clear, responsible language for discussing Accessibility without guesswork. It keeps conversations honest, practical and grounded in service possibilities. Key ARC resources for sales teams:

• Product or Service Compliance Level under EAA, ADA, AODA, etc.
• Knowledge-base articles,
• Feature conformance reports,
• Demo scripts,
• Limitation statements,
• Customer‑facing FAQs.

Use these resources to explain features in simple, respectful terms. Start by asking what the customer needs, then match those needs with verified capabilities. Keep claims rooted in ARC evidence so expectations stay realistic. When a feature has limits, state them plainly and kindly. Record customer requirements and promised follow-up so nothing gets lost. Use approved ARC phrasing to keep every sales channel aligned. This approach builds trust, protects integrity and reflects a commitment to serving others with care.

Support Teams

Support teams guide people through real challenges and help eliminate barriers. The ARC gives them structured steps, approved terminology and reliable information so they can respond with clarity. Key ARC resources for support teams:

• Troubleshooting guides,
• User flow test logs,
• Escalation paths,
• Bug report templates,
• Accessibility priority matrix.

Use these tools to gather accurate details, offer practical workarounds and escalate issues. Document steps clearly so designers and developers can reproduce barriers without delay. Track recurring issues using ARC dashboards and share patterns with product teams. Communicate timelines and follow up when fixes arrive. Every interaction becomes an opportunity to serve with dignity and steady guidance. This strengthens relationships and improves the product.

Artificial Intelligence

AI can help customer‑facing teams work faster and stay aligned with ARC guidance. It supports accuracy without replacing the human responsibility to speak with care. Potential AI uses:

• Surface relevant ARC articles during live conversations.
• Suggest approved phrasing based on ARC language and terminology.
• Flag risky statements that may over-promise.
• Summarize the test results in plain language.
• Pre‑fill bug reports with structured details.
• Highlight trends in support tickets for program owners.

AI helps people stay consistent, make fewer mistakes, and use reliable information.

Other Topics for the ARC

This article closes the ARC series. I hope the journey helped you support teams clearly and responsibly. The ARC covers more than previously discussed. It can grow to include many other areas, including Workplace Accessibility.

Workplace Accessibility involves removing barriers in the workplace. Those related to hiring, onboarding, communication, tools, physical spaces, and daily work processes. It’s legally required in various jurisdictions. When workplaces are accessible, every other area described in this series becomes stronger. An inclusive workplace with disabled colleagues cultivates both understanding and a sense of responsibility. Customer-facing teams understand real-world needs. Designers and developers build with broader insight. Leadership gains clearer visibility into risks and opportunities.

As the ARC expands, it is wise to seek guidance from Certified Professionals in Web Accessibility (CPWA). Their expertise ensures the ARC is trustworthy, practical, and values-driven.

Reading Time: 4 minutes

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.

Reading Time: 2 minutes

Integrating an Accessibility Resource Centre (ARC) into the project lifecycle empowers project and product managers (PMs) to embed accessibility across all project phases.

The following are some examples of practical forms and processes that PMs can use to align projects with Accessibility. They help deliver accessible digital products, ensuring compliance, quality, and user satisfaction.

Integration Management

• Formally include accessibility goals in the project charter by using an Accessibility Charter Template.
• Use an Accessibility Integration Checklist to ensure accessibility is embedded in all project plans and deliverables.

Scope Management

• Use an Accessibility Requirements Form to define clear, testable accessibility criteria.
• Use a Scope Change Request template to evaluate and approve any modifications impacting accessibility.

Schedule Management

• Use an Accessibility Milestone Checklist to align accessibility reviews with key project phases.
• Implement a Schedule Impact Assessment form to estimate the time needed for accessibility tasks.

Cost Management

• Use an Accessibility Budget Estimation template to forecast costs for training, testing, and remediation.
• Track Accessibility Expense Logs to monitor spending against the budget.

Quality Management

• Use an Accessibility Test Plan template to define testing scope and methods.
• Use an Accessibility Defect Reporting template to track and resolve bugs.

Resource Management

• Maintain an Accessibility Roles and Responsibilities Matrix to clarify team member duties.
• Use a Resource Allocation Form to assign accessibility experts and tools.

Communications Management

• Use Communication Plans that include accessibility updates and training schedules.
• Use Feedback Forms to collect stakeholder input on accessibility progress.

Risk Management

• Apply Accessibility Risk Assessment Checklists to identify potential barriers early.
• Use Risk Mitigation Plans tailored to accessibility challenges.

Procurement Management

• Use Vendor Accessibility Compliance Checklists during procurement.
• Include Accessibility Clauses in contracts to ensure supplier accountability.

Stakeholder Management

• Implement Stakeholder Engagement Plans that highlight accessibility education and involvement.
• Use Training Attendance Logs for tracking participation in accessibility workshops.

Artificial Intelligence Support

• Examine accessibility data using AI dashboards to identify weaknesses in your processes, products, and components.
• Use AI-driven content review tools to flag potential accessibility issues.
• Create all previous forms and processes with AI, following accessibility rules, success criteria, and laws.

The ARC should include all templates, process descriptions, and checklists for consistency across projects. Always seek the advice of a Certified Professional in Web Accessibility (CPWA) to customize these resources in alignment with your organization’s unique processes, products, and culture.

Next article: “ARC: Enabling Designers and Developers.” Practical guidance and trusted references help creators build accessible products without slowing delivery or creativity.

Reading Time: 3 minutes

In the previous article, we explored how a solid framework anchors an Accessibility Resource Centre (ARC). Let’s now focus on the practical side: the tools and resources that make accessibility work possible and repeatable.

Think of an ARC as a carpenter’s workshop. The framework provides a sturdy workbench, but the tools hanging on the wall make the craft possible. Each tool serves a purpose. Some cut, some measure, some polish. When used with skill and purpose, they shape digital environments that are both strong and welcoming.

Foundational Tools

Every ARC needs a dependable set of instruments ready to use. Start with a core repository of testing tools:

• Use tools like Axe DevTools and Microsoft Accessibility Insights to find coding problems early on. Also, tools like Access Continuum can even integrate into the development pipeline.
• NVDA, JAWS, and VoiceOver are screen reader software programs that make real-world user testing possible.
• TPGi’s Colour Contrast Analyzer and WebAIM’s Contrast Checker assess colour contrast for readability.
• The ARC Toolkit, AMP, and SiteImprove Checker extensions test live and staging sites, including secure and dynamic content.

Keep licenses current, standardize versions, and document usage. The ARC should be the single source of truth for everyone across the company. Everybody should use the same tools in the same way.

Knowledge and Reference Libraries

Beyond tools, the ARC’s bookshelf should hold the organization’s accessibility wisdom. This includes:

• Concise WCAG 2.2 summaries customized for your environment.
• Testing protocols and escalation workflows.
• Templates for conformance statements, accessibility roadmaps, and status dashboards must be available.
• Include training guides for designers, developers, and project leads.
• Procurement and vendor accessibility checklists.
• Organize it like a blueprint cabinet: indexed, searchable, and version-controlled.

Training and Practice Environments

Practice makes perfect; therefore, an ARC thrives when people can experiment. Create practice environments where teams can:

• Test new widgets with assistive technologies.
• Preview designs with simulated disabilities.
• Track the accessibility dashboards to show progress.

By getting hands-on, we make following rules a skill and make policies an experience.

Collaboration and Communication Tools

Accessibility grows through communication. For ARC documents, use SharePoint, Confluence, or Notion. Quickly connect with others using MS Teams or Slack. Schedule “Accessibility Office Hours” where experts can guide colleagues through issues. It builds confidence and community.

External Partnerships

Collaborate with certified accessibility professionals, universities, and technology vendors. They provide perspective, audit support, and testing opportunities. These collaborations ensure the ARC stays connected to real-world users and evolving standards.

The Role of AI in ARC Improvement

Artificial intelligence can now act as the ARC’s digital assistant. It can cross-reference topics and identify outdated or overlapping content. This helps governance teams see how accessibility goals align and identify gaps. AI strengthens coordination and maintains accuracy, allowing humans to focus on assessment and ethics.

A Culture of Stewardship

Tools alone do not build. Skilled and responsible people do. The ARC must cultivate stewardship, teaching teams to care for their tools and methods, maintain their libraries, and pass on good practices. In this way, accessibility becomes a shared craft that unites purpose and precision.

The true measure of an ARC is not the number of tools it holds, but how well they are used. Seek advice from Certified Professionals in Web Accessibility (CPWA) when choosing the right tools for your ARC.

Next article: “ARC: Project Lifecycle Integration.” Integrating ARC into delivery cycles enables better decisions, less rework, and make project outcomes more measurable.

Reading Time: 2 minutes

In the previous article, we considered why all organizations should have an Accessibility Resource Centre (ARC). Now, let’s explore how to build a framework that transforms accessibility from idea to working system.

An ARC framework is the backbone of lasting accessibility. It gives structure, clarity, and consistency, not ideology. Its purpose is practical: to make digital products and services work well for everyone, barrier-free. It supports business efficiency, legal compliance, and customer satisfaction.

Governance Structure

Governance gives Accessibility direction and authority. The ARC needs a formal mandate, a leader with influence, and defined accountability. Knowing who’s in charge makes things clear and keeps accessibility a priority in all projects. Leadership commitment turns accessibility talk into action.

Operational Model

An ARC defines how teams engage with accessibility. How reviews happen, and where checkpoints fit in the project lifecycle. Integrating accessibility into design, development, and testing avoids late-stage rework and protects quality.

Documentation and Standards

Documentation builds a strong framework. Put all accessibility rules, design instructions, examples, and tests into one easy-to-use place. Clear documentation makes accessibility predictable, measurable, and teachable. It also helps newcomers learn faster.

Training and Enablement

Training ensures accessibility doesn’t depend on one champion. Provide role-based learning. Developers learn to code for accessibility. Designers learn barrier-free layouts. Managers learn how to track compliance. Include coaching or office hours so staff can ask questions about real projects.

Measurement and Reporting

You can’t manage what you don’t measure. Dashboards and scorecards track accessibility audits, issue resolution times, and training completion rates. Sharing those results motivates progress and reinforces accountability. Transparency builds trust, inside and outside the company.

Technology and Tooling

Technology keeps accessibility efficient. Automated testing tools catch errors early. Assistive technology labs allow teams to understand how users experience products. AI helps find accessibility problems, but human review is vital.

Departmental Integration

In large organizations, one ARC rarely fits all. Each department or product line may run its own ARC adapted to its technology stack. The central ARC council coordinates consistency and shared learning across departments.

Expert Partnership

Building an ARC requires specialized know-how. Engage qualified professionals, including Certified Professionals in Web Accessibility (CPWAs). They ensure your framework meets standards, and its contents match what’s needed in the real world.

An ARC framework isn’t bureaucracy; it’s structure with purpose. It builds accountability, protects users, and reflects respect for human dignity. Accessibility done right is good design, good ethics, and good business.

Next article: “ARC: Tools and Resources.” The practical instruments your ARC needs to operate and deliver lasting value.

Reading Time: 2 minutes

In today’s digital world, companies must follow rules. Digital Accessibility is now a requirement. Organizations must comply with regulations. Adherence to standards is mandatory for digital products and services.

Now, accessibility further defines a digital product’s quality and longevity; thus, its business value. Yet, most companies still address accessibility issues by fixing them as they arise. A smarter approach builds accessibility from the start. That’s the role of an Accessibility Resource Centre (ARC).

Organizations use different names for this type of centralized accessibility repository. Terms such as Digital Accessibility Hub, Accessibility Portal, or Accessibility Center appear across sectors. However, the underlying purpose remains the same. In the Canadian context, and particularly within major institutions such as the Federal Government, the term Accessibility Resource Centre (ARC) is the most widely adopted. So, I will use “ARC” for consistency throughout this series since I am based in Canada.

An ARC puts together resources to make accessibility part of the product or service delivery. Such resources are usually a compilation of tools, expertise, and governance documents. It’s a central hub on the accessibility topic.

In small companies, a single ARC can support everyone through shared knowledge and resources. Cross-functional groups can start by putting references and checklists in a cloud folder.

Large companies usually put ARCs on SharePoint sites or wikis. When having multiple ARCs, stakeholders categorize them by business sector or specific technologies. E.g., they could have an ARC for digital banking, one for enterprise software, and another for mobile applications.

An ARC delivers value across the company by reducing guesswork and rework. For project and product managers, it provides legal frameworks, maturity models, and checkpoints. Developers and designers benefit from access to code libraries, design patterns, and testing tools.

Teams that interact with customers will also benefit. ARCs provide sales teams with product compliance details, enabling confident responses to client inquiries. Customer support staff get guidance on accessibility-related issues. This ensures that the correct teams receive reported problems with the right details.

A solid ARC is more than just a repository of documents; it’s an ecosystem, and it might include:

• Accessibility testing tools and assistive technology simulators.
• Accessibility regulations by jurisdiction, along with legal advice.
• WCAG-aligned design systems and UI pattern libraries.
• Reporting templates for accessibility bugs and support tickets.
• Accessibility statements and conformance reports, such as VPATs.
• Training modules, recorded video sessions, and certification pathways.
• Contact information for accessibility testers and consultants.

These resources help all departments, from engineering to communications, to work towards accessibility. An ARC mitigates legal risk, improves usability for everyone, and strengthens brand reputation.

Implementing an ARC requires a certain level of know-how. It involves understanding both technical standards and the organizational shift required to implement them. That’s why companies should always seek advice from accessibility experts. Usually, a Certified Professional in Web Accessibility will ensure an ARC follows industry standards and rules.

Digital Accessibility is a shared journey. An ARC is the compass that keeps everyone moving in the same direction.

The next article will focus on “ARC: Building the Framework.” Creating structure, rules, and assigning responsibility helps accessibility efforts succeed long-term.

Reading Time: 6 minutes

The hard part of Web Accessibility is empathy. By that, I mean the part where a development team has to emulate users with disabilities to provide a solution. As opposed to sympathy, which is just caring about the Web Accessibility cause, and saying: “somebody should do something about it”. But then, navigating and testing (hands-on) while emulating users with disabilities is hard, and a process. A slow one.

Of course, hiring people with disabilities to do the testing and providing feedback is the best solution. Unfortunately, this is still not a widespread practice. Most of the time not in the hands of designers and developers to do the hiring. However, emulation is a good strategy, while keeping in mind certain details.

So, empathy equals user emulation, and user emulation is hard. This “hard part” proves to be hard most of the time because it’s usually not “on the radar” of the “usual” development practices. Hence, most of the time not “visible” to team members. The hard part is usually harder when neglected from the very beginning of a project. At that point, it just seems like a very time-consuming inconvenience to retrofit everything. The latter is unfortunately the most common approach to Accessibility. Retrofitting takes 10 times longer compared to what it could have taken if done “from scratch”.

Nevertheless, the “from scratch” approach generates a high level of anxiety among developers and stakeholders of the project. It gets perceived as if they are spending too much time in proper code semantics. Not in actual features and functionalities. Then we hear: “time is money”, “the client wants it for yesterday”, “not enough resources”, etc. Yes, all of the above, also makes part of a hard truth: “no features, no sales”.

Annotations to the rescue

Tackling implementation with Web Accessibility Annotations makes it less time-consuming. Even when developers aren’t “that much into emulation” or are still ramping up their accessibility knowledge. With annotations, they will know what needs to be there, code-wise, and why.

That said, a lot of time could be saved if Web Accessibility is considered at early stages. Like while UX Design and Visual Design stages are starting. If Web Accessibility Annotations are clearly communicated to developers from the beginning, they will be able to implement them faster. Of course, best if crafted at the very beginning. Most common categories for these annotations that will help speed up projects and make the hard part less painful are:

1. Accessible Keyboard Patterns being standard.
2. Labels and Descriptions provide context for all users.
3. Headings make sense if nested.
4. Landmarks and Regions are well organized.
5. Status Messages are meaningful and punctual.
6. Screen Reader narration UX.

There are great design tools to communicate Web Accessibility Annotations. They can also all be communicated to developers with a spreadsheet or a text document. Yes, it’s time-consuming to populate a spreadsheet with all those details, but it’s worth the effort in the long run.

By keeping in mind some details under each category, we will be on our way to crafting them correctly.

Accessible Keyboard Patterns

Keep in mind:

• Keyboard navigation is the foundation for most Assistive Technologies. All UI components should work with the keyboard or provide a similar experience while using the keyboard. Source order matters, avoid breaking it, and thinking it can later be arranged using CSS grid or absolute positioning.
• There is already a standard for Common Keyboard Interactions for most UI components, no need to reinvent the wheel. Have a cheat-sheet handy with all those included in your UIs, to avoid regressions.
• Not everything on the UI is about “tabbing”. There are other keys on the keyboard as well. Some are exclusive to Screen Reader use. 

Labels and Descriptions

Keep in mind:

• All form elements and buttons should have labels. Text in label should make sense when audible (when vocalized by a Screen Reader).
• A placeholder is not a label, use both, even if repetitive, or be creative to avoid repetition.
• Don’t be afraid or annoyed by repetition. What may seem straight forward for some users, may not provide enough context for other users. Be inclusive: design, develop and deliver for all users.
• Screen Reader users will get context from the labels and descriptions they hear. Trust your eyes, but also trust your ears. If you don’t hear it’s not there.
• Don’t overuse aria-label, it’s invisible to sighted users, and it will override text in native labels for Screen Reader users.
• Provide descriptions through aria-describedby attributes to give Screen Reader users more context if UI is complex. Use visually hidden text styles to provide context or instructions if you can’t provide aria-describedby due to code practices reasons.

Headings

Keep in mind:

• Headings are for arranging or structuring content on a page. Not all big font instances have to be headings. Choose wisely.
• Most Screen Readers allow “headings navigation” by just pressing one keyboard key, H key for JAWS/NVDA. Make sure the heading structure will make sense if users were to skip content by headings. Will they land on meaningful content?
• Most Screen Readers can produce a list with all the headings on a page. This allows users to browse the list and jump to a specific heading on the page. Write down that list and structure it. Does it make sense if you read it out loud?
• Some Screen Readers like NVDA will “nest” headings when listed. Organize your headings in a way they make sense, similar to an expandable Table of Contents.

Landmarks and Regions

Keep in mind:

• Similar as with headings, Screen Reader users can list, navigate, and skip landmarks and regions by pressing only one keyboard key, R or D key for JAWS/NVDA. This is a capability only Screen Readers have. They must be well organized and make sense when listed.
• Screen Readers will announce when users enter and exist a region or landmark. If you have more than one region or landmark of the same kind, then label them for differentiation. E.g.:
  • <nav aria-label=”top navigation”>
  • <nav aria-label=”breadcrumbs”>
  • <nav aria-label=”footer navigation”>

Status messages

Keep in mind:

• If you remove something from the UI, don’t assume the user will “see” it’s no longer there. That’s not enough for Screen Reader users, they also need to “hear” it’s no longer there. Use aria-live or role=”status” to notify user of any changes that may affect them.
• Same as the above but for element that weren’t there before. Notify users when new elements are introduced on the UI.
• Don’t overuse role=”alert” this is a very aggressive and intrusive kind of notification. Use only when needed, for everything else use aria-live. 

Screen Reader narration

Keep in mind:

• The Screen Reader user experience should make sense throughout the whole user journey. Think of it as a person telling you over the phone what they are doing at every step. The “listening experience” should match the user interactions. Write it down and make sure developers receive it. Along with specs, wires, and visuals.
• Silence is bad. Knowing beforehand how the UI should “sound like” will help spotting and fixing silent spots.
• Use proper semantics. A link is not a button, even if you make it look like one. Screen readers will vocalize the true nature of the element and users will act according to what they hear. Screen Readers can also list Buttons and Links separately, so they should make sense when listed apart. 

When browsing the web it’s clear that keyboard interactions, code sequence, labelling and status messages are probably the most neglected issues. Then, in my experience, thinking we can later rearrange the order of the components with CSS Grid, and enforce focus management with JavaScript, sets the ground for very unpleasant surprises.

Other Pain Points

• Tables can also be problematic, especially if responsive. They are a complex topic worth an article, or several, of their own. Noted in my to-do, for a later time. For now, keep in mind Screen Readers can also navigate by Tables on desktop, T key for JAWS/NVDA, and have their own keyboard interactions. Therefore, semantics matter quite a great deal here. Oh! … and they sound different on mobile.
• Form validation is also complex, although it could be very simple. It’s a controversial topic mainly due to the overuse of “dynamic validation”. It looks great visually, but it’s not very inclusive for Screen Reader users. They will hear an error as soon as they start typing. Creative solutions are needed to produce an inclusive UX. This topic too deserves its own article(s).

To wrap up, and clarify. Let’s not be fooled by thinking Web Accessibility Annotations is all that’s needed to get Web Accessibility Implementations done. They are just part of the specifications. It’s a reference. It helps. But it helps even more when team members are familiar with Screen Readers’ use and interactions. With how components and elements sound like. Then annotations will be accurate, UI/UX and code-wise. Like an audible mockup.

Reading Time: 4 minutes

I often get questions about where to start implementing web accessibility. If there are easy parts to WCAG, and if it’s OK to start from there.

Yes, there are easy parts to WCAG. The easiest parts are those you really don’t have to do. Non-applicability, I mean all those success criteria that do not apply to your product or website. According to WCAG’s definition of conformance. If there is no content to which a success criterion applies, then the success criterion is satisfied. Consequently, there is great value in identifying those first. Every project is different, but for instance, if you don’t have video or audio in your project. In that case, you can skip those parts completely.

In my experience. I would say anything in the realm of automatic testing is easy. Easy to test, easy to fix. Then things start to get difficult when we need to manually test the User Interface. Mainly because there is a steep learning curve as to how exactly it needs to be tested and by who. Therefore, testing for Screen Reader is the most difficult part, in my opinion.

The easy parts

Now getting back to the easy parts. The following are easy: non-text content, sensory characteristics, use of color, contrast, page titled, link purpose, multiple ways, consistent navigation, consistent identification, language of page, link purpose and maybe error identification too. Mostly all those things on the web designer’s end. It almost seems logical to start there. Although, in my experience with transactional websites, these are huge time wasters. I’m not saying don’t implement them, they must, but not first. Change or adjust them at any time. However, implementing them first usually gives a false sense of accomplishment.

By the way, I’m intentionally removing the success criteria numbers in the previous paragraph. Removing the numbers makes articles more digestible, some readers have told me, especially for beginners. It seems numbers give the article a technical flavor. So, I will do this when possible. This is not a technical article, it’s more of a cautionary tale.

The disadvantage

One disadvantage of starting with the easy parts is thinking your website is accessible because an automated test says so. Tests such as Chrome Lighthouse, may indicate your project is 98% accessible. This could be misleading for your project stakeholders (e.g., client, high management, project manager, developers, designers, etc.). Especially if they are not familiar with web accessibility and falsely think they have reached a near-perfect accessible website. As it turns out, automated tests only cover 18 to 20% of the accessibility issues. And doing it so, page by page.

It should be clear: there’s no replacement for manual testing. So, if you make it to 100% in Lighthouse, that’s really only 20% of the accessibility for the tested page. Not for the full website. I have come across this misconception many times. It’s demoralizing for stakeholders and developers, finding out there is still a remaining 80% work to be done. Once they thought it was ALL done.

It’s also tempting for some stakeholders to claim a site is “half-accessible”. By taking fulfilled success criteria based on non-applicability, and then add them to the previous automated test percentage. Inflating numbers is a terrible idea. This doesn’t make a site more accessible.

So, where to start?

I have heard many times the claim that the first 3 steps to Accessibility are “easy”. Those steps being: Keyboard Navigation, Form Labels and Automated tests. I agree with this approach, but I kindly disagree with Keyboard Navigation being easy. The more interactions you have on one single page, the more complex the Focus Management becomes. However, I definitely agree Keyboard Navigation is the best place to start, even if it’s not easy.

Form labels, in a perfect world, are easy only if using native HTML elements. Yet, a rarity in real life these days. The more developers use <div>s and <span>s for everything while coding forms, the more dependent on ARIA roles and attributes those forms will be. Once crossing the ARIA imaginary point-of-no-return, then the next thing we will run into is Accessibility Patterns. Defining or reconstructing these patterns takes a lot of focus management work. Not an easy task past that point, but a must-have by then.

Anyway, in my experience, implementing the “hard parts” first sets a foundation. To support what you will add on top. The previously mentioned easy parts. Accessibility is not a one-time project, it’s a process. There could be regressions and we want to know where they are and how to avoid them.

Hard parts are time consuming

Yes, it takes time to do the hard parts first, and time is money. In real life, stakeholders get desperate with deadlines. Developers want to start features and functionality without mockups. Managers want to add look and feel quickly to show progress. Those efforts need direction. Developers for sure can start features, but making sure they are operable with the keyboard, not just the mouse. Progress on design is perfect as long as it doesn’t break keyboard navigation.

If you are working on a website that the client will customize later. Then fine-tuning contrast, fonts size and use of color is something you can put at the bottom of the to-do list. Better to concentrate on building on top of the keyboard navigation experience and visible (and audible) labels. But here’s the thing, this is also no different if you are working on a website that is “final”. Meaning the client won’t customize further. In this case, keyboard navigation will give designers better arguments as to where to place components. Other than just “design trends” or fashionable practices. It’s harder to roll back a component’s position and break keyboard navigation, than it is to roll back from color, contrast, or size changes.

Having said all that. The hard parts don’t have to be “that hard”. UX designers can help from the very beginning. By identifying things like Intended Keyboard Patterns, Visual and Audible Sequences, Minimal or Specific Screen Reader Narration.

The choice is yours. As I said before, every project is different. Just don’t let the easy parts consume the time you could be spending on the difficult parts. Accessibility needs to be implemented gradually, like onion layers, following Inclusive User Journeys. Instead of just literary complying with success criteria without understanding their meaning.