1. Accessibility

2. Who’s this guy?
Ian Cooper Head of Planning and Performance (UIS) Chair of the UIS Accessibility Working Group
Ian Cooper is the Head of Planning and Performance in UIS. The presentation was given in his capacity as Chair of the UIS Accessibility Working Group, which was formed as a result of noting that multiple independent groups were forming.
Ian has experience of training blind and physically impaired users in the use of computers from about 20 years ago.

3. Real time closed-captioning
Real-time closed captioning from PowerPoint (o365, not ProPlus) Similar technology exists in G Suite
Subtitles by Vicons Design from the Noun Project
The presentation was initially planned to use the real-time closed captioning that is now built into the Office 365 versions of Microsoft PowerPoint (both PC and Mac). At the time of the presentation this was not yet available in the 2019 ProPlus versions of the software that are typically installed on shared machines.
I believe that similar technology is built into the Google G Suite

4. Accessibility Regulations
Full title: “The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018” Came into effect 23 September 2018 New websites compliant by 23 September 2019 Existing websites compliant by 23 September 2020
There is no definition of what “new” means. A site that has undergone significant revision would probably be considered “new”.
Office documents are also covered and there may be some work that is required on some of these.
Apps (for example on smartphones) are also covered but with a deadline in mid 2021

5. …but… There are some exemptions (including):
Extranets and Intranets: only content published after 23 September 2019, unless a substantial revision
Office documents
(Is a Content Management System a website?)

6. This is Cambridge, so things are a little different
This is Cambridge, so things are a little different. The definition of a “Public Sector Body” in the Regulation is the same used in EU Procurement legislation. The University has a High Court judgement in its favour that confirms that under that definition we are not covered. This implies we are not covered within the bounds of the Accessibility Regulation.

7. However! Other duties The Equalities Act (2010)
Required to make reasonable adjustments (so let’s just do it right from the start so it’s universally accessible)
The UK is a signatory to the UN Convention on the Rights of Persons with Disabilities
… and we’re Cambridge, and should be leading
Assuming that the University is not bound by the requirements of the Accessibility Regulation, we are still covered by the Equality Act (2010). If we choose to totally ignore everything the Regulation is motivating organisations to do we could fall into the trap of doing things that result in claims of discrimination against the Equality Act.
We should use the Regulation as a framework. We need to be particularly careful that we do not say things like “we are covered by the Regulation” or “as the Regulation requires” as this may call into question our assertion that we are not a Public Sector Body in the Procurement area.

8. So, what needs to be done Let’s Panic Later by wackystuff on flickr
We’re behind where we would like to be but we shouldn’t panic
Image from

9. So, what needs to be done?
Accessibility Statement (Probably for every website – not linking to a single policy)
Making websites (by way of their content) perceivable, operable, understandable and robust
WCAG 2.1 AA
There are two things that we need to focus our efforts on:
Writing accessibility statements for each website, which should conform to the common template published by GDS
Ensuring that our websites (and the content on them) meet the technical standard, which is WCAG 2.1 AA (Web Content Accessibility Guidelines 2.1 level AA)
At present we have a single central accessibility statement, which already states that we should comply with WCAG 2.0 AA. We cannot continue with a single central statement as the technical issues on each site will be different. The way that individual areas of sites operate (for example forms, image libraries, or document libraries) will also vary.
The process of writing an Accessibility Statement should provide a framework for auditing functionality and identifying areas that do or do not meet the technical standard.

10. Accessibility Statement: GDS guidance
“Your statement needs to cover:
whether your website or app is ‘fully’, ‘partially’ or ‘not’ compliant with accessibility standards
if it’s not fully compliant, which parts of your website or app aren’t currently meeting accessibility standards and why (for example, because they are exempt or it would be a disproportionate burden to fix things)
how people can get alternatives to content that’s not accessible to them
how to contact you to report accessibility problems - and a link to the government website that they can use if they’re not happy with your response.”

11. Template Accessibility Statement (oops)
The UIS Accessibility Working Group had hoped to publish a template Accessibility Statement and guidance by now. We are behind. But we’re also hampered by the late publication of the initial template by GDS (first published on 17 May 2019) and subsequent major updates (for example on 12 July 2019).
The sector has made GDS aware that it is unhappy about the delays and constrained timeline.

12. Technical measures: WCAG 2.1 AA
If you’re on a UIS provided Falcon or Drupal site, much taken care of already Moodle core platform – work under way, course materials need checking. Other UIS services being reviewed
Much of the heavy lifting for technical compliance is already in place, or will be soon, for sites that are based on UIS implementations of Falcon or Drupal. Work is taking places on the Moodle core platform but individual course material needs to reviewed. Other UIS services are also being reviewed.
If you operate a website that is new since September 2018 and not on UIS Falcon or Drupal you probably need to start auditing your functionality.

13. Structured documents: Spot the difference
One of the technical requirements is that documents are structured.
The slide shows screen captures of two Word documents. Both appear identical to a fully sighted user. However, one uses plain font manipulation while the other uses styles. The use of styles is critical to users of assistive technology.
Many of our users probably don’t understand that styles exist or almost certainly don’t understand why using them is good. This is largely because they haven’t been provided the appropriate training to learn these skills.

14. Structured documents: The difference
By turning on the document navigation pane it’s possible to see that the first document has no structure.
Use of styles isn’t just of benefit to those using assistive technologies, it’s useful to all.

15. Beware alt-text
Care needs to be given when reviewing web pages. For example, the UIS help and support website contains alt text for the graphics used as icons on the top level page and on cursory inspection all appears OK on that front.

16. Beware alt-text
If we drill down, however, we can see that the alt text that has been used bears no relationship to the intent of the icon.
In this case we believe this is due to an odd feature in Falcon, which the UIS Communications team only identified 10 minutes before this presentation. We expect to circulate some guidance on this issue.

17. Sharing best practice
Content Community – how to write in an accessible manner Next meeting: 31 July Technology Community – Rich is next…
The UIS Accessibility Working Group will be sharing information with the wider community shortly. Other activities related to accessibility are also taking place.
For example, the Content Community will be covering the topic of how to write in an accessible manner at its meeting on 31 July 2019.
We expect to publish a list of some simple “dos and don’ts” along the lines of the Home Office design posters.
In due course it would probably be appropriate for the newly forming Technical Community to discuss common ways of implementing accessibility elements across applications.

18. “Demo”
Video extracted from York St John University A blind student using JAWS (who is now employed in their equivalent of the Disability Resource Centre) Source video has captions

19. Video demo
The video demo is from the equivalent of the Disability Resource Centre at York St John University
The team from York St John University provided a real-time demonstration of JAWS at the Ucisa “Spotlight on Digital Capabilities” event in June 2019.
The user is occasionally stuttering on her speech because she is reading from her braille script.
Most people probably won’t be able to hear everything that JAWS is reading (and this is probably already slightly slowed down from what a JAWS user will listen to themselves). Note that the user will at times just be listening out for keywords (for example, “heading”)

20. Head of Planning and Performance
Ian Cooper
Head of Planning and Performance