In this guest post, Paul Bradley gives his thoughts on “How to Run Higher Education Website Accessibility Projects”.
How to Run Higher Education Website Accessibility Projects
It’s January 2019. The legal analysis is complete. Your university now understands its public website(s) needs to be accessible by September 2019.
And, in addition to everything else that was planned for 2019, you’ve been asked to prepare a project plan to ensure your institution will be compliant by the deadline.
In this article, we outline four basic principles on which to base a website accessibility remediation project and seven project plan elements for making an institution’s public website more accessible and meeting the deadline date.
Most higher education institutions will start accessibility projects lacking data about the scope and scale of the work involved. Experience tells us that stakeholders will not fully grasp this fact at the outset and will be surprised when timelines subsequently slip. Recrimination can be minimised by ensuring that:
- Stakeholders buy in to and clearly understand why an accessibility remediation project is needed. In discussions with website accessibility experts it has become clear that success goes hand-in-hand with making accessibility a core institutional value.
- The project leader has sufficient authority and access to resources for her role. Paul Boag’s recent article, Do You Carry All the Responsibility with None of the Power? addresses the problems of pushing projects too far down the hierarchy to achieve success.
At the Outset
With buy-in and appropriate project management in place, an accessibility remediation project will be more successful if four core principles are clearly understood. At ‘crisis’ moments project participants can refer back to the list.
- An accessibility remediation project is not a computer science exercise. Websites are a communications medium. They display content people create, in environments people program, for other people to consume. Appropriately trained people implement website accessibility with support from technology: not the other way around.
- Website accessibility expertise is in short supply. External expertise will be needed for planning and acquiring relevant knowledge and skills. In fact, training will be the most significant success factor.
- Document everything, as project stakeholders need updates. However, if the website(s) (and the associated remediation project) is externally reviewed, past experience with compliance regimes suggests documentation goes a long way to forestall trouble. As UK institutions have formal risk registers and you should also discuss with internal audit, or their equivalent, the implications of failing to meet the deadlines.
- Remediation should be a one-off exercise. Extensive training will ease a transition into an inclusive design process, in which accessibility is addressed proactively.
The Project Plan Elements
The Public Sector Bodies (Websites and Mobile Applications)(No. 2) Accessibility Regulations 2018 (“the Regulations”) sets out the following deliverables:
- Public-facing university websites need to be accessible as defined by EU standard EN 301 549 (in practical terms WCAG2.0) except when the burden of doing so would be disproportionately costly, and;
- Universities will need to produce (and keep up to date) accessibility statements explaining where and why content may not be accessible, alternative formats available and who to contact with accessibility concerns.
To meet these two deliverables and before diving into the complexities of accessibility institutions will first need to evaluate and catalogue which content types exists on their website(s), because:
- the Regulations exempt some content from being accessible – so, no need to assess this content for accessibility.
- assessing whether the burden of compliance is disproportionate requires understanding which content types (for example, PDF documents) may be too costly to remediate.
- keeping accessibility statements current and accurate will require tracking which new content types are added and where alternatively-formatted content is located.
It is unlikely that content management systems, in their standard configurations, can produce the needed information. You will need to develop or use third-party tools to catalogue the different types of content published across your website(s).
While an accessibility remediation project has its specific characteristics, the overall project plan will comprise a similar set of tasks to most projects:
- Needs Identification
- Objectives Setting
- Deliverables and Deadlines
- Human and Financial Resources Budget
- Roles and Responsibilities
- Project Schedule
- Project Monitoring
1. Needs Identification – do we have a problem?
Whether an institution sees web accessibility as fundamental, or it hasn’t given the topic any attention, it will need to size up the potential issues.
It’s January. The compliance deadline is nine months away. This is not the time to become a self-taught website accessibility expert. Find an existing website accessibility expert. In fact, find one who can train you, your development and your content editing/creation teams. Supplement external training with online resources, Slack channels, email lists and the like, but recognise problem assessment needs to be concurrent with knowledge acquisition.
After you understand the different types of content on your website(s), you and your accessibility expert need to conduct a website accessibility audit and in doing so, you need to address two issues:
The new web accessibility rules apply to exampleu.ac.uk, but do they also apply to botany.exampleu.ac.uk or student.rowingclub.exampleu.ac.uk? We don’t know either, but the answer matters for two reasons:
- You may have to first identify all the sites in your web estate before you can provide a clear answer on how many sites and pages the project will touch.
- Auditing a single, main, website is materially different from auditing hundreds of sub-sites or microsites.
To what depth?
Not all web pages are created equal. Web analytics data will likely show relatively few pages account for a high proportion of all site visits. Understanding how to fix these pages may address most of the initial concerns. On the other hand, these pages may not be adequately representative of a site’s content types.
A blended approach of checking popular web pages and pages designed to reflect a site’s different content types should identify both page-specific and systemic issues. The goal is to avoid being crushed by the weight of data from testing every page. That approach simply slows analysis and add only marginally to understanding the overall scope of work.
2. Objectives Setting – How much of a problem and what will we choose to fix?
With the audit boundaries set, the audit can proceed and will, in turn, comprise three elements:
(i) Automated Testing
Automated testing tools are analogous to word processors’ spelling and grammar checkers. These tools identify misspellings (but, may stumble on subject-specific terminology), automate making changes and can highlight potential grammar issues. What these tools can’t do is make poorly structured arguments sound or revise content to make its meaning clearer. Human content editors need to do the latter.
Automated accessibility testing tools can parse web pages and generate results from algorithmic comparisons with the relevant guidelines (for example, WCAG2.1). The results still need human interpretation. For example, an automated test may show that an image has alternative text, but can’t confirm that the alternative text is relevant or helpful.
We describe a number of the available testing tools in our blog post: 25 Tools to Test Higher Education Website Accessibility.
The more complex the test, the higher the probability the results will contain ambiguities that web team members will need to resolve. For a comprehensive review of why automated testing can’t be relied on read the following article from the Government Digital Service (GDS): What we found when we tested tools on the world’s least-accessible webpage.
To understand the issues automated testing can’t find or can’t identify unambiguously means turning to manual testing.
(ii) Manual Testing
Manual testing involves trained staff reviewing web pages for the types of issues that automated testing tools are not intended to identify, for example:
- Automated tests may not include rules to cover every condition that WCAG2.1 or WCAG2.0 guidelines address, so a page may pass but it still isn’t accessible.
- Navigating through a website using a keyboard.
- Interactive web page content can be difficult to assess in all its potential states, as determined by end user interactions.
- Web pages may contain syntactically incorrect ARIA mark-up that is not readily identified by automated software.
- Depending on the scope of accessibility being addressed, there may be issues with content ‘readability’ making it inaccessible to its intended audience(s).
Eric Bailey’s article in Smashing Magazine provides an excellent framework for performing manual testing: The Importance of Manual Accessibility Testing.
(iii) Functional Testing
The GDS has prepared a set of profiles highlighting that not all website users needing accessibility features are screen-reader users. However, testing website interactions with screen-reader software will highlight issues that apply to those that need these devices as well as those that do not.
Testing with screen reader software will need outside assistance as it is unlikely that your institution has the relevant skills and competencies, in-house.
3. Deliverables and Deadlines – How do we address what we have found?
The combination of accessibility testing approaches allows issues to be clustered into three groups for further analysis and resolution:
- Content-related issues – potentially needing manual fixes to current content, accessibility awareness training, new content standards and changes to content creation processes.
- Design-related issues – potentially resulting in changes to the user interface, site navigation and use of colour and other factors.
Breaking down the issues into these three categories should align their resolution with the typical split of higher education website support responsibilities.
Moreover, in each case further analysis can establish:
- The work involved in addressing and resolving identified issues. The Regulations recognise the burden of complying may be disproportionate and the audit output offers the data needed to make this assessment.
- The priority for resolving those accessibility issues that passed the disproportionate burden assessment.
- When deemed appropriate, how the institution will provide accessible alternatives to content that will not be remediated as the burden of doing so was deemed excessive.
Analysing the audit data is likely the phase during which external expertise will be most valuable in determining and deciding what will be addressed so as to:
- maximise accessibility in the available time, and
- be explicit about items that will not be resolved.
A detailed project plan can be compiled from analysis of the audit data to establish three key components: priorities, time line and resources.
Any specific remediation project’s priorities will be driven by the audit findings, but the following working assumptions may be useful;
- Fix the most popular website pages first.
- Maybe it is finally time to remove rarely-visited content?
- Develop a plan to avoid having to carry out another remediation exercise in future because of lack of content and site maintenance.
- Resolving errors generated by content management systems have sitewide benefits and the techniques used can be disseminated across campus to other independent groups using the same CMSs.
- Content creation issues can be the most stubborn to resolve as the solution lies in training and content creation process changes that have to take institution-wide to be effective.
It’s only a guess, but it seems likely the Regulations’ compliance deadlines were chosen arbitrarily and were not based on detailed analysis of the work needed to bring public sector websites up to appropriate levels of accessibility.
An audit may show there is too much work to complete with the resources and within the time available. Be explicit with your stakeholders that work will be prioritised to maximize the impact on accessibility issues by the deadline date.
A clearly documented project plan explaining the rationale for the chosen implementation priorities will help stakeholders understand why a particular approach has been taken and will help external ‘auditors’ see that reasonable efforts are being made.
Having categorised the audit results into content, development and design issues it should be reasonably straightforward to determine who and how many people will be needed to deliver the ‘level’ of accessibility flowing from the results analysis.
While content-related issues can be largely addressed as soon as they are identified, many content editors will need training to understand and recognise potential accessibility issues and resources will need assigning to fix existing content. Fixing current content may be a task that can be assigned to student resources?
Development-related issues will be more difficult to resource, as there is likely an existing development workplan for 2019 that adds new capabilities or meets marketing and communications needs for recruitment and other efforts.
In many organisations, development and design resources will be one and the same, so prioritising what will be fixed is especially important.
4. Human and Financial Resources Budget – What resources will actually be available?
All projects need a budget. But, this project will need some expenditure upfront on the software for automated accessibility testing and access to accessibility expertise in order to understand the resources that will be allocated to remediation.
For this exercise the overall budget will be bounded by the results of the disproportionate burden assessment, an institution’s commitment to accessibility and the changes needed to current content creation processes.
As accessibility training will be a significant ongoing requirement, in times of constrained financial resources, perhaps training costs could be shared with other near-by institutions?
Depending on whether an institution uses an open-source or proprietary CMS, the budget may need to include expenditure for supplier software modifications. Having said that, these costs typically get shared across a user base or suppliers make regulation-driven changes at no cost.
5. Roles and Responsibilities – Who is doing what?
As we noted above, clustering issues into three categories (content-, development- and design-related) helps clarify and allocate subsequent roles and responsibilities.
However, with all projects that change a website’s user interface and user experience, it is important to test everything. Many updates can simply be tested by the usual testing pool, but others will need access to end users, representative of the accessibility issues being addressed.
Longer-term, maintaining an accurate accessibility statement and fulfilling the responsibility to respond to accessibility concerns will mean allocating dedicated resources to this role. In our opinion, the sustainable value of web accessibility champions or web accessibility officers is ambiguous: pushing an institutional responsibility onto one individual potentially exempts others from having to be concerned about this issue.
In selecting an accessibility ‘person’ it is essential that the institution appoints at a senior level, giving them sufficient budget and authority to motivate everyone on campus that website accessibility is their collective responsibility.
6. Project Schedule – When do we stop remediation?
On the assumption that no website is ever fully accessible, it better to view accessibility as a process rather than a project. Put another way, accessibility is much like security, it needs ongoing attention and is never ‘done’.
Given that an outcome of the audit is to identify items that will be remediated and items that will be addressed by providing content in alternative formats, it seems sensible to aim to:
- make all identified design changes that are to be made by the first deadline date.
- address all identified development-related issues by the first deadline date
- make as many content-related updates as possible by the first deadline date, understanding that publishing accessible content will be part of revised content creation processes.
In other words, aim to have the ‘project’ transition to the new normal on 23 September 2019.
7. Project Monitoring
As with all projects, once approval to go ahead is received, stakeholders and project participants will need regular status and progress updates. Everyone needs to be regularly reminded why this work is being done and the institutional benefits that it will deliver.
While we’ve not mentioned the term ‘agile’, so far, it is likely that your institution has adopted this methodology in one form or another and this type of exercise seems well suited to taking the same approach.
And, when it gets to deadline day – celebrate and communicate the benefits to the institution’s set of audiences.
Every institution will need to provide an accessibility statement on its website to explain which content is not accessible (and why not), where alternatives may be found and how to get in touch about accessibility concerns.
Accessibility statements are important in two ways. First, they communicate how seriously an institution takes accessibility. For example, Zoom Video Communications (the video conferencing service provider) has an effective description of its service’s accessibility features that screams inclusion rather than reluctant compliance.
Their feedback role reinforces seriousness, but follow through is hard. We view a lot of higher education websites and we regularly encounter errors. Many of those sites have feedback or reporting forms that we duly complete. We almost never receive more than an auto-response email and the errors usually remain.
Many thanks to the following individuals who participated in interviews or read draft versions of this document. Any errors are mine.