Gavin Wray

Accessibility regulations, university websites and decentralised publishing

With six months left until the first of the accessibility regulations’ deadlines, I’ve been thinking about how different publishing models could affect UK universities’ preparations and ambitions for accessible web content. In this post, I cover the facts of the regulations, the risks of decentralised publishing, content debt and an idea for a transformative approach to accessible content.

The facts

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 came into force on 23 September 2018. The regulations transpose the EU Directive on the accessibility of the websites and mobile applications of public sector bodies into UK law.

UK universities must ensure that their websites and apps meet level AA of the WCAG (Web Content Accessibility Guidelines) 2.1 to comply with the regulations.

Deadlines for meeting WCAG 2.1 are:

  • new sites launched after 23 September 2018 have until 23 September 2019
  • existing websites must comply from 23 September 2020
  • apps must comply from 23 June 2021

There are exemptions for certain types of organisations. Also, exemptions and different deadlines apply to particular content types, such as intranets, archives and pre-recorded media published before 23 September 2020.

Practically, universities need to:

  • ensure that new content meets the WCAG standards
  • prioritise existing content for review and, if necessary, update it
  • plan how to assure that future content is accessible

Legislation prompts action

I’m pleased that accessible web content is a legal requirement in the UK. When the Equality Act 2010 came into force, which prohibited discrimination in access to ‘services’ (goods, services and facilities), attitudes to the usability of UK public sector websites improved.

Obligations for universities to comply with consumer protection law introduced in 2015 significantly improved the quality of web content for prospective undergraduate students, such as course descriptions.

I’m hopeful that the accessibility regulations will generate a similar step change in accessibility of university websites. The shift from best practice (optional) to a legal requirement (a risk of being sued), should push inclusive design to a more senior level of university decision-making.

Risks of decentralised publishing

Those universities with a decentralised publishing model may find it hardest to meet the regulations. I’m curious to see whether universities move away from this model towards a central, specialised team of content experts.

In decentralised publishing, anyone can publish to their organisation’s website without specialist skills. They typically use a CMS (content management system). There may be no review or approval stage. Where workflows exist, they are local to a particular team who have developed a process for themselves. Also, there may be no human (non-automated) check for compliance with WCAG standards.

The narrative in favour of decentralised publishing goes something like this:

  • web publishing is open and democratic, whereas IT or communications departments previously guarded access
  • entry to publishing is low
  • no delays waiting for another team to deal with content requests
  • content management systems make content accessible automatically
  • staff take ownership of their content

I fully support access to publishing tools and encourage others to develop their content skills. A sense of ownership over a website helps long-term governance. This approach works well in a small, multidisciplinary team with expertise in communications, technology, design and the subject matter.

Automated checks produce a report of how accessible your content is and flag potential issues. Accessibility is a scale of improvement though, not necessarily a pass or fail test to fix once. It requires judgement and iteration.

Automated tests and a CMS cannot:

  • take action to address problems
  • judge what improvements to prioritise
  • govern content autonomously

That’s what people do, and their skills change and develop with experience. After 15 years of learning about web content, I still refer to WebAIM’s guidance on alternative text regularly because there is such nuance involved.

As Louise Taylor, a software engineer at BBC Sounds, tweeted during a presentation by Heydon Pickering:

Improving your website’s accessibility isn’t a single task to tick off, it involves continuous consideration and a commitment to keep improving user experience #a11ylondon

The reality of decentralised publishing at scale, in my experience at a UK university, is that web publishing is seen as an administrative task that anyone can do. The assumption is that subject matter experts write material, while administrators proofread and upload.

For an administrator, looking after a website is an extra job on top of a full workload of coordinating their department’s everyday business. They’re expected to take on another skilled task while their department avoids the cost of staffing their digital activity.

Also, I often hear ‘we can hire a temp to do the actual content’. Current UK rates for a temporary web editor, communications officer or content developer via Unitemps are between £10 and £14 per hour. Pro rata, that’s between £19,500 and £27,300 per year. Such compensation is unlikely to attract a skillset that includes:

  • inclusive design
  • techniques for meeting WCAG standards
  • how to prioritise and address accessibility issues
  • questioning poorly-written content or whether the content needs to go on the website at all
  • handling a considerable volume of legacy content
  • copywriting and editing
  • tidying markup into valid, semantic HTML
  • iteratively improving content through analytics and testing
  • coaching contributors

Indeed Gerry McGovern said in 2013:

Decentralized web teams rarely reflect a professional approach to web management. They tend to be a cost reduction tactic.

When it comes to content, people are far more important than software. It’s much better to have five highly skilled content professionals than hundreds of content amateurs and a fancy content management system.

To be clear, I’m not criticising the people in decentralised teams. It’s the model itself that I struggle to accept because it adds extra workload to non-digital roles while devaluing content skills.

Content and accessibility debt

Universities that rely on decentralised publishing are those most likely to lack the mid- and senior-level digital capacity to cope with content debt, and now accessibility debt, at the scale necessary to meet the accessibility regulations.

A university website can have hundreds of sites under a single domain name. I’ve seen more than one teaching department’s website with over 50,000 pages and files.

To start dealing with the debt, rather than throw an army of junior editors at a Sisyphean task, I hope that UK universities will act more strategically. They could look to successful digital transformations at other universities, such as overseas, or sectors where modern digital practices are a default part of a user-centred culture.

Transformation

I would love to see universities first create an executive-level role for inclusive design with a remit that spans access to education, physical spaces, learning materials, offline and online services, and wellbeing.

Next, appoint a ‘head of digital transformation’ type of role with the authority to:

  • challenge the culture of decentralised publishing
  • assert control of content that does not meet accessibility regulations
  • restructure and support decentralised teams
  • recruit content expertise at all levels, from junior through senior to heads
  • introduce career progression frameworks for content, design and technology roles

Will universities invest appropriately in their teams and at the necessary levels of seniority to improve accessibility at scale? Who knows. I’m waiting to see which universities act first and who follows their lead.

Content © 2008-2019 Gavin Wray
Athena theme by Diana Mounter

Twitter · LinkedIn · SoundCloud · GitHub