The evaluation process can be time consuming at least. But it is worth. Now we can really dedicate our efforts to fixing accessibility problems.
But – what do we fix first? Where do we begin with accessibility improvements or even fixes?
There are different views on this matter, as always, but there are still some concepts that can be derived from classical bug-fixing and project management schools.
Accessibility is about users so I think it should be our priority to first fix the most user-facing issues and then make priorities there.
User is the sun in our galaxy, so let’s make sure we gravitate towards user needs first.
me
If users can use our solution then:
- we will less probably get sued as we are not disabling them,
- we will more probably have a bigger return on investment as they will be using our services,
- we will more probably rank higher in the search engines, because our solution will be used and maybe even promoted by the users,
- our good name will stay good 😀
So I believe we have to make our priorities by thinking of our users and also being practical at the same time.
There are problems that can span through all of our pages and can be fixed in a single, shared, component (for example a header navigation missing “skip to content” link) or maybe some form elements that we are re-using on multiple forms. Maybe a modal window implementation that needs a better focus management and you can probably think about multiple cases like this.
In this single page application oriented time it is not uncommon to re-use pre-made components from a central, even public repository – and there we can even contribute to the good of the whole community – by for example fixing an accessibility issue for our page or application and giving the fix back as a pull request to the open source project.
We need a new feature now, this accessibility fix must wait.
Random project manager that decided to prioritize new feature before a11y fix
There are of course also realistic views on this matters and I have unfortunately experienced business priorities over-prioritizing new features and causing not-critical accessibility issues being sent to the bottom of the backlogs just because new features were “more valuable”.
That should not happen and we must all do our part to prevent this, but the reality of the occupation can sometimes be like this. Especially on smaller projects and teams that do not treat accessibility as a first-class venture (yet).
So we must actually try hard to convince stakeholders, owners and teams about necessity of accessibility aspects of businesses. Luckily for us we get more and more awareness about accessibility from major organizations and even governments, but it is still necessary to integrate inclusive design and accessibility into decision maker and budget divider circles in all organizations.
Some additional views on prioritization:
- Karl Groves : Prioritizing Remediation of Web Accessibility Issues (opens in new window)
- Michigan State University : Prioritizing Web Content for Accessibility Review and Remediation (opens in new window)
- Kent State University : What is the RAPID™ Digital Accessibility Remediation Model? (opens in new window)
- University of Notre Dame : Prioritizing Remediation (opens in new window)
(You can probably define your own too. Please make sure you share it :D)
