The simplest and quickest way to get started is to only use the Core. In this example, we’ll give a scenario and how The Web Accessibility Framework could be applied.
This is one way The Web Accessibility Framework could be applied – it is not how the framework must be used.
Scenario
A department is part of a larger organization and wants to improve accessibility on the three websites they’re responsible for. They don’t have any accessibility experts, but the website content writer is responsible for all three websites and wants to find ways they can make them more accessible.
Applying The Web Accessibility Framework
In this case, using only the Core makes sense for a few reasons:
- The main goal is to start improving accessibility.
- They are just getting started with accessibility and getting started with the Core is a quick way to learn by doing.
- The department only has three websites and one person running them. That person is familiar with the current state so spending time defining it wouldn’t be as beneficial as getting started.
The department could still use Tiers or Profiles if they thought those would be helpful.
Remember, these steps are just an example and an organization could use different outcomes, choose more outcomes, incorporate tiers and profiles, or adjust it to meet industry-specific standards.
Step 1: Choose the outcomes
The Core has several accessibility outcomes. Organizations wanting to start simply can choose even just one outcome from each category. As you’re picking, some outcomes go together better than others. Picking outcomes that go together can help you go through the entire process smoothly.
These Core outcomes could be a good fit for this department because it would help them improve accessibility while also building processes and learning more about accessibility.
| Function | Outcome | Outcome ID |
|---|---|---|
| Identify | Critical or higher priority user paths are identified. | ID.AM-10 |
| Prevent | All users are informed and trained according to their role. | PR.AT-1 |
| Detect | Automated testing is scheduled on a regular cadence. | DE.AT-1 |
| Respond | Detected issues (or groups of issues) are documented and logged in central system along with non-accessibility issues. | RE.DP-1 |
| Remediate | Issues are remediated regularly. | RM.AI-1 |
Review the Core outcomes Google sheet or the Core information page for the complete outcomes list.
Step 2: Choose critical content
Applying these outcomes to all the content on all three websites could be overwhelming. Another option is to pick critical content to apply the Core outcomes to.
In this scenario, the department’s first outcome was to identify critical content. Even with that as one of their outcomes, they can pick one page or a small number of pages from the critical content to focus on.
Step 3: Go through the entire process
Now, the department can start working toward each of the selected outcomes. Here is an example of what this might be like for each outcome:
- Critical or higher-priority user paths are identified: The department used analytics and its own goals to find nine pages that were critical for its users. They selected the home page from each website to focus on first.
- All users are informed and trained according to their role: The website content writer started to learn more about making content more accessible.
- Automated testing is scheduled on a regular cadence: They didn’t have access to an automated testing tool, so they used the free, WAVE extension and decided to check existing critical content first and any content that is being updated.
- Detected issues (or groups of issues) are documented and logged in a central system along with non-accessibility issues: The department used Asana to track work and started documenting all accessibility issues there too.
- Issues are remediated regularly: Issues documented in Asana were prioritized with the content writer’s other work, so they could be fixed regularly. Issues that the content writer couldn’t fix were set in a backlog since they needed other resources to address them.
Step 4: Review
After going through the entire process, the department should review what they’ve done. Questions they could ask themselves are:
- What would we do the same? What would we do differently?
- Could we keep doing this process again to keep improving this website? Why or why not?
- Were processes put in place? If so, are they stable?
- How do we maintain these outcomes?
- Should we adjust or add outcomes?
- What resources if any do we need to sustain or grow this effort?
Step 5: Keep going
From here, the department can keep going with these outcomes, add to them, adjust them, or explore Profiles and Tiers to keep evolving their accessibility strategy.
This is an example using only the Core – it is not how the Web Accessibility Framework has to be used. An organization could use different outcomes, choose more outcomes, incorporate tiers and profiles, adjust it to meet industry-specific standards, or make any other changes to meet their needs.