Requirements gathering
At the start of any project the requirements need to be established and agreed. Within that you need to define what level of accessibility must be met, how it’s achieved and measured.
Simply stating a site must be Web Content Accessibility Guidelines (WCAG 2.0) Level AA compliant is not enough. Unless there is a clear outline how to achieve and measure this, it just becomes a footnote that is forgotten, overlooked or ignored.
As an organization you may already have a level of accessibility that all projects must meet. This could be referencing WCAG, internal guidelines or another organization’s guidelines. Once decided you should document how success is to be measured via a combination of audits (internal or third party), user testing, user acceptance testing, automated testing and suchlike. Rounding this off is the all-important decision of how each stage of the build is signed off and by whom.
It’s also important to define your delivery contexts (web, mobile web, apps, games consoles, TV etc) and accessibility requirements. Often these get overlooked or forgotten but are just as important.
To help you plan you can always download a copy of BS 8878 Web Accessibility Code of Practice, a framework for accessibility to help website owners and commissioners deliver accessible websites.
Tenders and contracts
If some or all of the build is going out to tender simply requiring a ‘WCAG 2.0 Level AA’ compliant sites is not enough.
Add to tenders questions that will really probe if organisation’s have existing processes in place to deliver accessible website. Ask for a portfolio of previous work, accreditations, testimonials, what they do to train their teams, what level of compliance they recommend (if they say WCAG Level AAA they’re not the ones!) and ask how they test internally.
In the contract clearly state what you expect and how you will verify success (external audits, automated and manual tests etc.), provide them with any organisational guidelines or best practices you have and clearly state if they do not meet your criteria for success then they won’t be paid. Harsh, but it get’s results.
The team
Your team is your most valuable asset so invest in them. Establish early on what training needs they have. Even if they’ve had training before refresher courses are advised. This could include technical, editorial, design or screen reader testing training [See our accessibility training courses for how we could help]. If working with third parties on part of the build include them in shared workshops.
Invite real users to come and talk to you team at the start of the project and see if anyone will volunteer to be an Accessibility Champion or Technical Architect for Accessibility.
Documentation and processes
With goals and expectations set, documentation needs to be in place to outline how you get there. Embed and sign off accessibility with each key deliverable of the project. For example:
- Design specifications
- Functional Design Documentation
- Information architecture
- User acceptance criteria
Accessibility should seamlessly integrate into existing processes and systems. If you have a wiki, shared folder or intranet, add documents and findings there. Building up code libraries and shared inventories for alternatives and wording for headings and labels is also useful especially if you are deploying your product in different delivery contexts (web, mobile, apps etc.) or languages.
If you use a bug tracking system such a Jira set up master tickets for accessibility so you can track progress and get sign off. This is also a great maintenance tool post launch.
Build and test
Before the first line of code is written the structure of a site, semantics, behavior and alternatives should already be documented in the IA, functional design documentation and editorial documentation. If this has been done correctly there should be less of a disconnect between proposed designs and how the developer brings them to life.
Your developers should have the testing tools in place to test as they go along so that by the time the site is tested in it’s near complete state it is more of an exercise in signing off accessibility.
User testing with people with disabilities is most beneficial when done early on in the process, so make sure that prototypes are built in the technology they are to be delivered and in with accessibility in mind. It’s no good using an inaccessible Flash prototype for what will be a complex website if your users can’t test it.
Launch and maintenance
Having gone through the above steps your pre-launch checklist should have written itself. This will include signing off the user acceptance criteria, passing audits and automated testing. Many sites also choose to provide an accessibility statement. It doesn’t have to be long but it’s a useful way of confirming to your users that they can expect to be able to use your site. If a checkpoint can’t be met for any reasons then document why it’s exempt and add it to your accessibility statement. Transparency is often the best policy.
Ensure that you have a feedback mechanism in place and clearly available in the site. Ensure someone is tasked with monitoring feedback working with both your customers and teams internally to get issues fixed.
Post launch a maintenance plan should be in place. This could be regular automated testing and manual spot checks. If you can’t do this in house there are plenty of companies who can do this for you such as Spotless Interactive. This is vital on a site that is large and changes daily. Ensure someone in your team is assigned the task of processing maintenance checks and scheduling fixes.
Finally, sites evolve, new content is added, microsites, games or apps launched. With each major release or upgrade go back to the start of this process and reuse and evolve as much as you can. Remember to also train new recruits in how you work as a team to deliver accessible websites.
Summary
Much of the groundwork for accessibility happens before the first line of code is written and it’s the Project Managers job to see that this happens. Careful planning and documentation at the start of a project will offset the risk of costly mistakes being unearthed further down the line before website are launched or, worse, post launch.
Project Managers are not the sole architects of accessibility however. In the next in this series we’ll be looking at the role of the Information Architect.
About the Author: Tim Fidgeon is a writer for Spotless Interactive, a leading UK-based usability agency.
Processing your request, Please wait....
