Accessibility for Project Managers
Henny Swan - Published: 03rd Oct 2011 09.30 GMT
This article looks at the role of the Project Manager in delivering an accessible website. Itís the first in a series looking at roles and responsibilities within a team as they work together to deliver accessible websites.
Each member of a team has a responsibility linked to their particular skill set however itís the Project Manager who has the overview of the project both in terms of vision and implementation. A good Project Manager will recognize this and do what they can to give clarity and support teams in delivering their piece of the project.
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.
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.
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.
Need some more information?
If you would like to learn more about how we can help you run and co-ordinate accessibility testing then please call us or email us below and we would be happy to help out where we can.
We are ready to answer your questions right now, so please contact us by telephone on +44 (0)207 168 7526 or drop us a quick email firstname.lastname@example.org and we will do our best to help you with any questions you might have.