Making IT accessible for all! Transcript

• Presentation recording
• Presentation resources

Tamsyn Smith: Good Morning everyone. Welcome to “Making IT Accessible for All!” It's lovely to see so many people joining.

My name is Tamsyn Smith and I'm Senior Learning Designer Team Lead at the University of Southampton and I'm a white woman in my early 40s with shoulder length brown hair for anyone who's not able to see me, and I'm joined this morning by Dr Fiona Strawbridge, Director of Digital Education at UCL and Matthew Deeprose, Senior Learning Designer at the University of Southampton.

You'll see we've just popped some polls in the chat there for you to be able to answer.

So, this session will be recorded so please keep your cameras and microphones off unless we’ve come to you for a question, but we would like to encourage you to post any questions and comments that you might have in the chat box.

It is possible to turn on captions if you want them - they're automated captions. You can select the ellipsis and choose to turn on live captions. A recording with corrected captions will be made available via the presentation website. Likewise, the PowerPoint, relevant links and more will be available online afterwards. We’ve got two PowerPoint slide decks, the one we use in this session, and a fuller version with more details.

We’ve got various points where we’ll pause for questions, as well as having a few minutes at the end of the presentation.

As we’ve only got an hour to cover a huge topic, we have assumed that everyone has some knowledge of accessibility. My colleague Matthew has shared acronyms in the chat, if there is anything you'd like clarification for though please just ask and hopefully somebody will be able to explain for you. We’re hoping that after this session discussions will continue in the Jisc Accessibility Community in Teams.

So, as I said in the chat you should find two polls to answer, ‘Does your IT department have an accessibility policy?’, and ‘Does your it department have an accessibility testing process?’ So, you might need to scroll up in the chat a little bit to find those, but if you could complete those while we're starting the introduction that would be great, thank you.

Experiences of the past 18 months, as well as legislation, have demonstrated the importance of accessibility. For University IT departments this brings a range of challenges: How can we respond to these expectations? What about our policies and processes? University IT departments support a large number of services. What is achievable with limited resources?

But we need to think also that there are many opportunities. An important part of accessibility is helping all users to understand and use accessibility features. Accessibility skills are in-demand among employers, so developing such skills in our IT staff is a great opportunity. Adjusting our processes and practices, for example by annotating wireframes for accessibility, or building an accessible component library can bring efficiencies, allowing us to create new services and sites that are accessible first, and delivering an improved user experience. We do need to be realistic - when procuring or developing new services there may be obstacles to providing a fully accessible experience. We will show you methods for prioritising accessibility defects and taking ownership of accessibility. We have the opportunity to develop IT services that are “Accessible by design”.

So, why concentrate on IT departments? We can’t deny that an institution-wide approach is ideal.  It helps us to secure a mandate, budget, and buy-in from the University executive. But IT departments have particular attributes, they are responsible for most, if not all, of the University’s digital estate, so implementing technical solutions that meet accessibility guidelines can only really be done by the IT department. They tend to be embedded within their institution, touching almost all aspects, and are often looked to for leadership. IT departments can have a significant impact, and they have the chance to act now.

In this presentation we will share some background to put accessibility trends in context and introduce you to a pathway for implementing digital accessibility within your IT department. We’ll share practical examples of how accessibility can be embedded within the policies and processes of an IT department. But we won’t have all the answers – we’re all at different stages of this journey but as a community we can share practices and progress.

We're going to have a poll to find out where everyone thinks they are. We’ve adapted, with permission, this opening table from the McNaught / AbilityNet Accessibility Maturity model. Consider the mindset and actions of your IT department regarding digital accessibility, where do you see yourselves on this maturity model? Are you hoping that no one will ask about accessibility? Or perhaps you have added an accessibility statement on the corporate site, but not taken much other action?

Compliance with standards is vital but fixating on standards will not realise the maximum potential. Taking ownership and adapting policies and processes for accessibility should lead to sustained delivery of services that meet accessibility guidelines and will help to ensure that IT staff know and understand the benefits of accessibility. The highest level of maturity is working in partnership with users (including those with disabilities and impairments) to co-design and test services. In our presentation today we will be focussing on standards, ownership, and partnership levels of maturity.

Before we get into the main part of our presentation, let’s consider some of the context of Digital Accessibility.

Disabled students now make up a sizeable minority of the student population. The number is under-reported because many students will not show in the official data. Research from Advance HE found the proportion of University staff disclosing as disabled has almost doubled within the last decade. Accessibility affects all of us, everyone will experience some kind of disability or impairment at some point in their lives. But accessibility isn’t only about supporting those with a disability or impairment. Accessible practices benefit everyone.

Increasingly, we have opportunities to normalise and expand the benefits of accessible practices to all and explain the wider benefits. Nicola Yap, a Technical Writer for Google Cloud, has written that we should reframe accessibility as customisation. Accessibility features can benefit everyone. It’s important to explain these benefits to our user-population so that they can make more effective use of our services. Research shows that the more diverse an organisation the more likely it will out-perform, but how can we foster that diversity unless our services are accessible?

We mentioned earlier that we presenters are all at different stages on this journey, and it’s fair to say that we are all very far from meeting our goals and objectives within digital accessibility. We identified several possible pathways to follow for embedding digital accessibility within our policies and processes.

The World Wide Web Consortium’s Planning and Managing Web Accessibility guide is a straightforward and digestible approach to implementing digital accessibility within an organisation. It breaks down the path through four steps: initiate, plan, implement, and sustain. Each of the steps has a discrete set of activities. In the full presentation (which you can access online) we explain all of these and relate to them to the context of a University IT Department. During the rest of this hour we’re going to concentrate on what we believe will be most important and valuable for you. We will discuss learning the basics, developing the business case, creating a policy and determining budget and responsibilities, reviewing our websites, integrating goals into polices, and prioritising issues. We will then give an overview of the recommendations for sustaining these activities. The whole W3C guide is available online and the link is available on our presentation support website.

Now I’m handing over to Matt to start reviewing this pathway and its context for University IT departments.

Matthew Deeprose: Thank you Tamsyn. Hello everyone and thank you for joining us today. I’m Matthew Deeprose. For those who don’t see me I’m a bald white male, in my forties, wearing a black jacket and a green shirt.

In this first stage, initiate, we’re concerned with developing an understanding of accessibility and building departmental enthusiasm. By learning the basics, we mean finding out what accessibility is and why it’s important. The better you and your colleagues understand accessibility, the more effectively it can be implemented and promoted within your department.

Research by the charity Scope found that 40% of households include a member with a disability. So, talk with colleagues, friends, and family members with disabilities about their experiences.

On the support site, I’ve added some useful introductory resources. If you haven’t tried it yet, the Accessibility Maze is an online game that you and your colleagues can play to learn more about accessibility. You could sign up for an automated email that teaches you a little about digital accessibility each day. For example, “10 Days of accessibility” and Web Content Accessibility Guideline (WCAG) of the day”. And there are numerous online communities and mailing lists.  All these links are on the presentation support site.

As you learn about accessibility - try out a few of your own websites by using a keyboard, or using a browser-based accessibility checker. For example, load up your corporate site and go through the process of ordering a prospectus using your keyboard – can you successfully complete this workflow without using a mouse or trackpad? Or, install the free accessibility insights browser plugin from Microsoft and try running a “fast pass” on a few of your sites and services. Automated tools are not sufficient for complete accessibility testing but they can identify issues that should be simple to fix. How many issues can be identified automatically [on your sites] and what are they?

A strong business case helps gain buy-in from stakeholders and can make accessibility a departmental priority. In this context, what do we mean by “business case”? It may be a “stockpile” of arguments or elevator pitches, or it could be a project business case, or a report or position paper. Regardless, the aims are that through your arguments being tailored to your department, you can gain buy-in, set accessibility as a priority, and ideally obtain financial support. What’s relevant to explore in the business case will vary between institutions. In the next slides I’m going to highlight a few different angles.

We’ve mentioned accessibility features can be considered customisation features. In online meetings, it’s likely that someone has asked for a screen share to be made larger. This is dependent on the application reflowing, which is an accessibility Success Criterion. Our business case can explain the benefits both of our services following accessibility guidelines, and how by explaining these benefits to our users we can help raise effectiveness and digital literacy.

Not to diminish the experience of those with permanent disabilities or impairments, we may find ourselves dealing with a temporary impairment such as a broken arm, or a situational impairment such as using our device in a bright light. As the W3C says, “accessibility is essential for some, but useful for all”. Following accessibility best-practices will help to maximise the potential of our investment in online services for everyone. Many accessibility features could be thought of as “dormant” within the computers of our colleagues. Simple techniques such as having your email read aloud to you or knowing how to turn on dictation features can benefit many. So, a key part of our business case could be showing the benefits to all our users.

Review your institution’s access and participation plan to identify disability disclosure trends. Learn about your institution’s access and participation goals and consider how improvements to digital accessibility will align with those goals. So much of the University experience is digital, accessibility plays an important part.

Most would agree that ensuring our services are accessible is the “right thing to do”. Or even just “the thing to do” – if we weren’t ensuring the accessibility of our services before, our work was not complete.

Many will have become aware of the requirement for accessible digital services through the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 which I will now refer to as “PSBAR”. The regulations set testable standards for web sites, documents, and mobile apps to meet in order to prove their accessibility, and a way for organisations to report on their compliance. Failure to comply with the accessibility regulations, could result in: an Equality and Human Rights Commission investigation, a discrimination claim by an injured party, or reputational damage.

The legalistic approach should not be the only argument in your business case. As Lainey Feingold, a disability rights lawyer in the US, writes, it may mean organisations stop at the point of standards compliance. The organisation Web Accessibility in Mind has published a hierarchy for what motivates accessibility change. They believe the lower elements: guilt, punish, and require are not necessary for effective motivation, even though they are the most commonly used. Rewarding, enlightening and inspiring are much more powerful, try to consider this in your business case.

Implementing accessibility has development benefits for our IT staff through growing their marketable skills. Research by the Wall Street Journal found that the number of job listings with “accessibility” in the title increased by 78% in the past year. There is a growing demand for IT staff who are competent in accessibility and this will only increase.

You can find more ideas on the W3C’s website and in the full slide deck. Before we look at the planning stage, I’ll hand over to Tamsyn. We're going to spend a couple of minutes just looking if there are any questions from the chat. Over to you.

Tamsyn Smith: So we haven't had any specific questions posed so far Matt, but there has been some interesting discussion around the IT accessibility testing process or what people have got in their institutions. So, whether they've got an IT accessibility policy or whether it's something institution-wide. So, I don't know if there's anybody who's got any other questions they would like to ask at this point. Put your hand up if you've got a question. No? Okay so if we move on to the next section then.

Matthew Deeprose: Okay then! Careful planning is critical to effective implementation of any accessibility effort. It ensures a clear assessment of the required work, distribution of tasks, and continual follow-up on progress. Now, we had a poll earlier and I made some notes of the results at the time. They might have changed by now, but when we asked whether your IT department had an IT accessibility policy, I noted down 31% didn't know, 6% didn't have one and didn't have plans to have a policy, 23% were starting to consider it, 10% said that they've got one but it hasn't yet been approved, and 29% said that they have one and it has been improved which is really impressive.

Now I’m going to hand over to Fiona who’s going to share her experience of building an IT accessibility policy, establishing responsibilities and requesting budget and resources. Later I’ll share our approach to building accessibility testing capability. Over to you Fiona.

Dr Fiona Strawbridge: OK morning everybody. I'm Fiona Strawbridge. I'm the Director of Digital Education at UCL. I'm also overall responsible for digital accessibility at UCL. I'm a white woman in my mid-50s. I actually like to think I look closer to 30. I guess that you know at UCL, rather like other institutions, the PSBAR regulations which Matt mentioned, prompted us a couple of years ago to kick off a project to help to address the requirements and as part of this we did a lot of work on awareness raising, on training, fixing key content, testing applications.

But you know a couple of years in, it felt like the project is doing everything, and really we need to shift from that dependence on the project and to put things to, you know, to put things right, towards individuals, staff, and projects, taking responsibility. And in order to do this, to make this shift, we need to make clear what staff and projects are responsible for. And this really means creating a policy that we can point people to.

I started by drafting a policy for our Information Services so, you know, for the IT side of things. And when I presented it to the IT leadership team, they were very keen. They're very positive about it. They were very keen to broaden it into a whole institution policy.

I'm not able to move to the next slide. Tamsyn, can you help me out here? Please?

So, our institutional policy includes digital products, services, platforms, whether they're developed in-house or brought in. Also, online content on websites, intranets, and so on. Digital documentation, where it's going to be shared with others. Multimedia - obviously audio, video and images, and we have a separate section related to teaching and training content. You know, resources, presentations, multimedia documents to do with teaching and training, and the reason that we've separated that out is that the requirements of our policy for teaching are less stringent than they are for more public facing, and that's largely because there is such a huge volume all the time of teaching and training content being developed, and I think we'd have a rebellion from the academic community if we were too hard on them at this stage.

So, the style of our policy, it's written in, I hope, pretty simple language. There's a little bit of an example there, and I will be willing to share our policy in about a week’s time and I'll explain why at the end. But we, we've got simple language. We, you know, talk about, “must do, should do”, and there are links throughout it to more guidance which we have on our website.

The policy in terms of the IT side, we are looking for compliance with WCAG 2.1 AA as a standard. We're also looking for evidence that from the suppliers about what they're doing, their commitment to accessibility, and if we need to procure a product which isn't really good enough from an accessibility perspective. Then the person who is sponsoring that purchase needs to complete an exception report which needs to be reviewed outside of the project to get sign-off. We will then be looking for suppliers to agree with us before we start… we exchange contracts, how the accessibility issues are going to be handled. Testing of products happens for everything and we will be having accessibility statements for all digital products and services.

So next slide please, Tamsyn.

Getting the tone right is tricky. We've engaged a lot with stakeholders. Some are telling us that the policy is too stringent and demanding and others are saying it's not tough enough, which probably means we were in that least worst place in the middle. But it is a balancing act.

In terms of the roles and responsibilities, for general content, so for teaching content, for content on web pages it is down to the individual staff to make sure that what they're producing is accessible. That will be built into the policy.

For things that we are procuring, then it's the project managers who are responsible for making sure that we are procuring accessible products. The budget holder for that work is the accountable person.

For services and applications that we're developing in-house, project managers again are the people who are responsible for ensuring accessibility, but the CIO, the Chief Information Officer, my boss, is the accountable person.

We recognise that in particular for teaching materials significant work is involved to get everything really up to scratch, and so we've managed to get funding for two additional posts, one of whom will be supporting academics with specialist content, maths stuff and symbols, phonetics and linguistics have particularly interesting alphabets. And another [post] for more general support. And we're also going to be funding student time to help to tag images and correct transcripts.

In terms of signing off the policy, I'm going to the EDI [Equality, Diversity and Inclusion] committee on Monday to present it, and then to an Education Committee on Tuesday, which is why I said I'll be more comfortable to share what we have after I've got through next week. Ultimately, we’ll go to academic board, which is all of the professors at UCL, which is going to be a fun one, but we have shared the early drafts with key stake stakeholders, disabled staff and students, and EDI champions and I do feel it is a very good start for us.

Matthew Deeprose: It’s Matt here again. We had another poll earlier asking about your IT accessibility testing policy. I was quite impressed. While 22% did not know if their IT department had an IT accessibility testing policy or process, 8% didn't have one, but 49% are doing some accessibility testing informally, and a very impressive 19% (at the time - the results might have changed by now) said that they did have a formal testing process which is really impressive! So, I hope that during the Q&A right at the end we might be able to hear more about how people are handling this. I'm going to tell you a bit more about why we should do this and what we're doing at Southampton.

So we've got a policy, we've thought about it, so it's time to review our existing websites within the scope of our objectives. This allows us to identify issues to be fixed in existing websites and avoided in future releases, creating a baseline for future work and identifying where training is needed. The results are really useful in stakeholder reporting activities. We can highlight existing problems and their impact so that later on, the impact of positive change can be put into context.

University IT departments are likely to support hundreds of services, of differing complexity and technology stacks. First, we should prioritise and group the services to be reviewed, looking for the greatest opportunities for our learning and benefiting our users.  This will vary between institutions, but areas to consider include usage and priority or other areas that I have listed on-screen. Then, we should consider how we will perform the testing.

Within the Digital Learning team at the University of Southampton, we’re building an accessibility testing process. Our process grows with our familiarity and confidence in accessibility testing. It’s scalable so that we can build team capacity. It’s broken down into four levels, the first level was inspired by the approach of the Central Data and Digital Office (The CDDO). They use an automated testing tool, correlate and check issues found manually, then do a keyboard navigation and browser zoom check. Only if serious issues are found at this stage is a more detailed audit likely.

Our internal testing service is based around these four levels. The first is the baseline test, mimicking that of the CDDO. The second level is based around the “W3C's Easy Checks” which are designed to be quick and easy, rather than definitive. The nice thing is that on the W3C website they have video guides on how to perform those tests. Alistair McNaught and Abi James have documented similar tests that can be completed with limited knowledge and tools. The nice thing about the way that they've presented it is that they have a word document you can download, so that you can have a consistent format for your reports at this stage of testing, because being able to compare sites and services and their results can be quite important.

Now, as our understanding grows we are building up our level 3 testing process. I’ve added a link to it on our presentation support site. Our aim is to reach the level of competence that we can potentially follow the Website Accessibility Conformance Evaluation Methodology to perform a full audit.

Even with the results of a Level 1 test we can start creating Accessibility Statements for services and sites as we review them. Earlier, Fiona mentioned the importance in her policy of having accessibility statements for all sites and services which of course is our [legal] requirement. While accessibility statements should have a minimum set of information, there is an opportunity to add more details that are relevant and useful for our users. Promoting and communicating our statements can help to reinforce awareness, demonstrate that we care about removing barriers to the use of services, and encourage reporting of accessibility issues, helping us identify new ways to improve our services and remove accessibility barriers.

While automated tooks do not cover all accessibility issues, command line tools such as Axe can be used at scale to identify issues across sites. It may help to identify “quick wins” that can be remediated just by adjusting some CSS in the case of colour contrast or adjusting the headers in the case where the viewport has been set to disable text scaling and zooming. Identifying systemic fixes can help create momentum. It’s a positive way to communicate progress to secure greater commitment.

Before we look at the implement stage, I’ll hand over to Tamsyn to see if there are any questions from the chat. Over to you, Tamsyn.

Tamsyn Smith: Thank you, Matt. I think there's mainly some questions for Fiona so far and I can see she's answered the question from Mike about how the policy will be monitored. The other couple of questions there for you Fiona are whether the IT accessibility policy is just for the IT department or whether it's university-wide, and also whether it's aimed at staff and students or just staff.

Dr Fiona Strawbridge: Yes, so the first policy I drafted was aimed at the IT department and our directors were very keen that we broadened it into an institutional policy so that's what we have done. I mean it is aimed more at staff than students. The staff are under contract to do what we require of them and they are the people who are providing content on our websites generally, so it is aimed at staff. But with a lot of our training, it's open to staff and students alike so there's nothing to prevent students from engaging but it is very much aimed at staff.

Tamsyn Smith: Brilliant thank you Fiona and I can see the next question from Ruth is a nice segue into the next section, “are there any testing methodologies aligned to agile practice, for example testing components rather than pages on an ongoing basis rather than at snapshot audit points?” So, Matt, don't know whether to answer that at this point or whether you'd like to continue and then perhaps we'll have that covered in the next section?

Matthew Deeprose: Yes! Well, that's a fantastic question, Ruth. I'm going to be talking a little bit about some ways that the testing and other areas can be aligned with agile, but in the full presentation deck available on the website I posted earlier I've got much more material and also in the related content sidebar I've got a link to a blog post I wrote about aligning accessibility with agile so take a look at that when you have a moment.

I'll continue with our presentation now where I'll touch on some of that, but that is quite an exciting opportunity and particularly for us at Southampton we've recently all gone through agile training, and I know that at UCL, Fiona's team have already for a year or so been dealing with things in an agile context, and I think it's a very exciting way to implement accessibility and get that kind of engagement and excitement happening as well. So, I'm going to continue now and I'm going to be talking about the implement stage. This is where we embed accessibility throughout our processes.

How can we integrate the goals from our accessibility policy within departmental processes? We’re aiming to ensure that accessibility is considered an integral part of day-to-day activity.

Considering the cost of bugs, the sooner we find them the less they cost to fix. This is no different for accessibility issues. So, the sooner we consider accessibility within our IT processes the better.

Shifting left means testing earlier within our IT development life cycle, and this can be applied to accessibility as well. So, testing for accessibility. Considering accessibility when building, designing, and gathering requirements, and adding accessibility gateways within our change and release processes.

There are many available options in use in the field, let’s start by looking at building new sites and services. Free Accessibility linters can be added to interactive development environments that add a kind of accessibility spell check for developers. Both commercial and open source options are available that allow for automated accessibility testing to be built into the Continuous Integration process. Now, thinking about Agile, Behaviour Driven Development is often used to document and design a deliverable around the behaviour a user anticipates. A method often used for this is Gherkin. Gherkin is a business readable language which helps to describe business behaviour without going into technical implementation details. Writing accessibility requirements as Gherkin tests is an effective way to make accessibility expectations explicit.

This leads us into areas to consider when designing. For our services to be “accessible by design” it’s important to involve users with disabilities and impairments in the process. Within a University you’re likely to have both student and staff groups who would be happy to be involved. It’s important to recognise their contribution and time, particularly for testing. A really interesting example at the University of York is a group of student screen reader testers.

Every university is likely to have a brand with colours, fonts, and other design “tokens”. Optimising the design system for accessibility, for example by using only a subset of a brand palette which has sufficient contrast, can be the first steps toward building a component library. At the wireframe stage it’s recommended to include design intent so that developers don’t have to second guess how a design is meant to be accessible. Sarah Pulis and Claire Webber of Intopia have shared their accessibility annotation library for use in Figma. In this example headings, tab and reading order are annotated.

Thinking about requirements, we can add accessibility within project documentation, for example requiring creation of accessibility statements, and include accessibility within the “Definition of Done”. On the support site we share a role-based example of this, on screen, are examples for a content creator and a developer. For commercial solutions we can require an Accessibility Conformance Report, an accessibility roadmap, lobby our vendors to prioritise accessibility, and include accessibility within non-functional requirements.

In terms of our change and release process, we can require accessibility statements to be published or updated as part of go-live for new services or change approval for a significant upgrade. And set automated reminders for when accessibility statements should be reviewed and updated. We could include a section for accessibility testing within request for change forms as well as an entry for noting whether an update to the accessibility statement will be required. Continuing on from our point earlier about using automated tools to scan our sites for accessibility, there are examples online of using this data to populate dashboards.

While the graphic I’ve used is being presented in a more waterfall style format, this is just as applicable in Agile.  As I mentioned earlier, in the full slide deck, I’ve added sections from the Agile manifesto and how they can be related to accessibility. But to show you one today…

The art of maximising the amount of work not done is always an attractive proposition. Semantic HTML almost always has accessibility baked in. Compare on the left the amount of extra effort required to make a button keyboard accessible with the semantic example on the right.

While all accessibility objectives will need to be met, prioritising can help you achieve them more effectively. It’s important to build motivation by demonstrating initial success. Finding issues that are straight-forward to fix can be an effective way to do this. Examples might be adding really clear focus indicators that meet the new WCAG 2.2 criteria, or changing “click here” links to be more descriptive.

We saw earlier how automated testing can help to identify systemic accessibility issues that might take less time to fix. The accessibility of templates, components, and visual design can help to scale improvements and drive efficiencies. Changes in the organisation can also bring opportunities, for example the adoption of a new brand or service improvement programmes, for example migrating away from PDF forms toward more automated processes can give opportunities for accessibility as well. Procurement and recruitment are also important for scaling and sustaining accessibility. It probably goes without saying that if we plan to retire systems, we can deprioritise fixing accessibility issues within them that we find. How can we prioritise the accessibility issues in general?

The Agile Accessibility Handbook has an excellent methodology for prioritising accessibility defects. Critical issues are when a business-critical function cannot be used by someone with a disability. Think of it in the same way as you would if the whole organisation could not perform this function. Serious issues are like critical issues but where there is a workaround. Moderate issues affect non-essential functions and that have a workaround. Minor issues are those that would be distracting but do not affect functionality.

Before we look at the sustain stage, I’ll hand over to Tamsyn to see if there are any questions from the chat.

Tamsyn Smith: Thank you, Matt. We've got a range of questions cropping up - quite a few of them in relation to usability testing and accessibility testing, seeing accessibility testing as a subset really. I’m not sure whether we've got enough time to sort of focus on that right now, but if there was anything in particular people wanted to ask, if you want to put your hand up or we can come back to that at the end. I think some of those questions have been answered so far as well.

Matthew Deeprose: I can see there’s one there from Joe Grant about user stories and acceptance criteria. I think probably… I think the idea really is to look at where you can add that checking for accessibility throughout. So, definitely within user stories -  and we had those examples of creating those Gherkin style tests so that developers who might not be so familiar with accessibility have this kind of explicit expectation set of how things ought to work. Looking at where we can leverage automated tools with continuous integration and continuous deployment, and also with regression testing that we could use automated tools to make sure we're not bringing back old issues that we had already fixed. Including accessibility in the Definition of Done which kind of maps towards acceptance criteria. So, I think having as many points as possible where we're considering accessibility and ideally starting to build that component library so that we're not having to create an accessible modal [for example] from scratch for each new service that we build - that we can take something off the shelf where a lot of that has already been considered. Although even with a component library with accessibility baked in once, we're integrating components together we still need to do that accessibility testing to make sure that nothing creeps in that we haven't considered before.

I'll move on to the next section if that's sounds good and I think we'll have plenty of time for questions and discussion at the end as well.

Embedding accessibility within our processes is so important because we’re aiming for accessibility to be within all our IT department’s activities. What do we do to sustain our accessibility efforts?

We should monitor our services, both in terms of automated tests, and as services are upgraded, redesigned, or our processes change. When you find issues it’s a great opportunity to refine training and processes.

Keep working with your stakeholders, for example, raising awareness of your accessibility activities and the benefits. If you have set up Key Performance Indicators, check that they remain relevant. Seek long-term engagement within your IT department. Champions networks and communities of practice can help to sustain the momentum. On the support site I've added a link to some workshop activities that Tamsyn and I designed for our Community of Practice for accessibility within our IT department. Keep talking to your suppliers and monitor their accessibility roadmaps.

Keep track of changes to standards and legislation. Updates to the Web Content Accessibility Guidelines are around the corner. The Government will be publishing its reflections on the first year of monitoring soon.

New technologies bring new opportunities. There’s always a new operating system, browser, development framework. The accessibility community is regularly sharing new, optimised practices that you can benefit from.

Most importantly, invite user feedback and use it to help guide improvement activities and identify areas in need of attention. Keep communicating accessibility improvements and how they benefit your user community.

Now I’ll hand over to Tamsyn to bring us to our conclusion.

Tamsyn Smith: Thank you, Matt. So yes, as you said, we’ll conclude by summing up what we’ve covered and some final thoughts.

We put some accessibility trends in context and introduced you to a pathway for implementing digital accessibility within your IT department, sharing practical examples. So, we said we didn’t have all the answers – we’re all at different stages of this journey, but as a community we can share practices and progress. We covered some aspects of the “Planning and Managing Digital Accessibility” pathway. The full slide deck covers all aspects of that pathway, made relevant to University IT departments and it’s available on our presentation support site, the address is go.soton.ac.uk/ucisa There you can find a number of further artefacts we have produced or collated, along with all the links we refer to in the slide deck. In a few weeks, the video of today’s session with corrected captions and a transcript will be available. Time for a few final thoughts.

In a recent interview, Karl Groves, founder of accessibility agency Tenon.io, said, “From a security perspective … you've got that pattern in your head ‘filter, validate, escape’. It's how you do things all the time. Same thing goes for accessibility, once you start doing accessibility it becomes how things get done and then it’s not extra work”. As we’ve attempted to show, embedding accessibility within our processes and practices makes it become just something that we do. The expected baseline.

We can go further, Alistair McNaught, the accessibility consultant says “…compliance does not guarantee a good experience any more than non-compliance guarantees a bad one”. It’s through the communication, partnership, and co-design that we can go beyond standards to make for a truly inclusive experience.

At the end of the full slide deck we’ve added a suggested roadmap for your next steps. We’ll try and follow up any questions we haven't been able to answer in a follow up that we'll send to you in the next few days. Continue the conversation on the JISC accessibility community and you might want to join their monthly drop-in sessions.

Thank you for your time today, and thank you especially to Siân Thomas and Richard Stone at UCISA for working so hard in the background to make this event a success. We’ve now got 15 minutes to go through any questions in the chat and open up for further discussion. We’re interested to learn what you have been doing at your institution. So, either feel free to post a question in the chat or put your hand up if there's something that you'd like to ask.

Matthew Deeprose: Any questions in the chat while we were talking, that we can pick up while we see if anyone has anything they want to ask?

Tamsyn Smith: well I know Simone [Waplington] has asked a question there about whether anybody's got any involvement with their technology departments or the computer science departments to support any of this work. I know Mike [Wald] has shared some of his experience from the University of Southampton. I don't know whether anybody's got anything else to add to that discussion, of whether you've been able to work with any of your departments? We've got a question for Fiona how will you share your policy with us post sign-off next week because people are really interested in that?

Dr Fiona Strawbridge: Well, actually I think Matt has done a bit of a number on the policy already and has shared the outline of it and actually quite a lot of the wording of it in the website which is shared at the top of the chat so you could take a look there and there have been some changes and I guess what I could do quite easily is to send the version once I've reworked it to Matt to put on in the same place.

Tamsyn Smith: Thank you, and we've got a hand up from Joe. So, Joe did you want to switch on your mic and ask you a question?

Joe Grant: Yeah! One second. Hi everyone, thanks that was a really useful talk and good to kind of see some experiences and some of the stuff in the chat. I guess the one from me was just more of a sort of discussion really - getting people's experiences. I think the challenge we've had is around kind of working with third-party suppliers. One because we don't always know who really is the university kind of contact / system owner of that supplier because it could be legacy. And also we've, you know, some suppliers have been really good and they've been really on board, you know, kind of almost pleased that we're kind of collaborating with them. And then other suppliers have done that thing of just kind of saying you know we're not a Public Sector Body and actually we don't fall under those regs, and in which case we've done an audit ourselves and done the statement but obviously that doesn't help does it? Like because obviously the thing here isn't it - it's not about ticking a box, “we've got a statement”. We want things to be accessible! So, I just wonder if anyone else had any experiences or had a response like that from a supplier.

Matthew Deeprose: Well, I can tell you what we've found is… I'm not sure that we've had quite that experience where someone has said that it's nothing to do with them, but we have been able to identify issues and raise them with suppliers, and also it's really important I think how valuable as we get together as a community that we can put that pressure on suppliers. I saw in the chat earlier, it might have been from you, Joe, or from someone else, about thinking about adding that kind of information into the frameworks that we might already be using for purchasing.

Joe Grant: Going forward it's been… obviously that, like someone's mentioned here, we've put things in place now, and, you know, we like to think we can build into the procurement process, and so I think the future is bright hopefully, but obviously the turnover of new digital services isn't that big, and we've got a lot of… you know our portfolio is quite big already.

Tamsyn Smith: We've got Dave Key with a hand up. I don't know whether Dave wanted to add to that one, or whether you've got another question?

Dave Key: Yeah, to add to that one actually. So, we, with Matt and Tamsyn, and various others at Southampton, have just started putting considerably more accessibility questions in our in our procurements and I kind of see it alongside [how] we've also just started putting a lot more sustainability statements in in those same procurements, and that they both seem to be resulting in a similar outcome where it's very hard to evaluate. Somebody can quite easily on the sustainability side, greenwashing is the term, where you can make a statement sound fantastic even if your credentials aren't great, and I think that that there's the same risk accessibility-wise. You've really got to ask quite a lot of questions, in quite specific ways to really understand whether somebody's got the right credentials and that institutionally means those things have to be really important and really strategically focused to say, “we're not going to buy that bit of software if it doesn't do these things”, and I think we're getting there with that and I agree that moving forward that's going to be the place that we need to get to. What we haven't done and the kind of retro fit, should be I suppose at re-contract time with all of the bits of software that we're going to continuously be using: we should be asking those questions at that point, but it's harder to crowbar them in, isn't it?

Dr Fiona Strawbridge: Can I just say, I mean one thing I've found quite productive is having really quite stiff conversations with suppliers. So Miro for example, one wonderful whiteboard app, but you know really didn't have a very clear accessibility policy, and you know we've had some good conversations with them. Now they've got an accessibility project. Now, I have to be honest I haven't followed up in the last few months to find out really whether they delivered what they promised but I did feel that we were making some progress. Echo 360 similarly had pretty poor automatic speech recognition and they were slightly denying how poor things were. We did some testing and we showed that, you know, compared with Otter and they were about, you know, five times worse. They looked at our comparisons and they re-tested and they realised that actually we were speaking the truth, and they have now shifted their speech recognition engine, and it's radically better which means that we need to spend a lot less time and money correcting transcripts because they're really very good now.

So, you can put pressure on organisations! I appreciate that because we're UCL, and we're enormous, and we have some clout, possibly that they will listen to us more than they might some smaller institutions, but I would encourage you to lobby or to talk to UCISA and JISC and you know to colleagues in networks like the Digital Accessibility Regulations Network to, you know, ask others have they had problems with particular suppliers, because if they begin to get the same message from multiple institutions they may start to listen a bit more keenly.

Joe Grant: Thanks Fiona, yeah that’s really useful.

Tamsyn Smith: Thank you. Right, we've got a couple of other hands up so Jill Hockley.

Jill Hockley: Hi there! Yeah, we had a similar problem with our service management tool that was implemented several years back, and then the company was taken over by an American company who had zero interest in accessibility pretty much. But what we did was, the HE (Higher Education) User Group and then the UK user group, basically have bombarded them. We've worked together and now they're implementing more accessibility and it's at the forefront of their enhancements. So again, it is just about I think we have to get together as a group for some of these companies and just go look we will say “goodbye” to you if you do not get on board with this. And that has worked.

Tamsyn Smith: Thank you, Jill. Julian Dobson?

Julian Dobson: Hello there! I'm business relationship manager at Goldsmiths University. Fiona you gave a really good workshop a couple of years ago when we could all meet in person about for the accessibility regulations coming in. You talked about the importance of having working group for that. I'm curious with Southampton and UCL who kind of your business - the focus of this is? What the IT department can do as a purchaser but who is kind of the business sponsor or stakeholder behind you? Because in Goldsmiths we have [the] disability team involved, we have communications team involved, but I'm, you know, I'm not sure who at Goldsmiths now, who is seen as the owner of accessibility? So, what is the situation in UCL and Southampton?

Dr Fiona Strawbridge: At UCL I think I realised that I'm in a senior position and I, you know, if I wasn't going to do it nobody was going to do it, and you need somebody, I think, senior to drive this and we could all argue that, “oh this is an EDI [Equality, Diversity and Inclusion] thing and they should look after it”. I mean I've got good backing from our Chief Operations Officer, so our COO and for our Vice Provost or our Pro-vice Provost for EDI. But really in terms of trying to drive this forward, I have to be the champion, which is actually frankly why in the last sort of 20 months things have got a bit stalled, because of COVID, because my role is also Digital Education and I've had other things on my mind, and so I feel that we haven't really made a lot of progress of late, but yeah you need somebody senior, but I mean there isn't an obvious owner because of the digital side, I felt that it was legitimate for me to do this.

Julian Dobson: Okay, just to comment around that, our disability team have organized training their big focus there is on, what you've already touched on accessibility, is about lowering barriers to everybody make it easier. So that's, you know, that has come from the accessibility team, which is more focused on students than on staff, but thank you for that.

Dave Key: Just to give you a view from the Southampton side, we're kind of in a similar position that we've got some really big strategic statements about EDI [Equality, Diversity and Inclusion] and an EDI strategy, but the actual doing work of making accessibility happen has been relatively few people including Matt and Tamsyn, and we've said we said that we'd start off working with the IT department to make sure that we don't kind of try and spread ourselves too thinly. There is a real groundswell of people sort of joining our Community of Practice, and the more we bang the drum the more people are joining in. But those two things aren't quite linked up yet. We're having conversations with the with the EDI teams but they're not saying, “we're going to own accessibility” at the moment it's kind of we're doing a lot of accessibility work and there's an EDI strategy and at some point they will naturally find each other and link up. But I think there's enough senior and strategic sight of the importance of this stuff that when we do activity it's being accepted and being kind of pushed up.

Julian Dobson: Thank you.

Matthew Deeprose: I'd just like to point out Peter Hirst's comment about, “we don't ask the mechanic to design the car”. and why focusing on IT departments might not necessarily be the right way. As we said at the beginning, an institution-wide approach with senior stakeholder buy-in is really important for getting that mandate, securing the budget, but I know what a lot of Tamsyn and I have been doing is trying to trying to push the needle a bit more forward to work where we do have some influence and to start raising this in the hope that as Dave said the it will eventually tie together which is definitely not the most effective or optimized way to do it, but we kind of felt we have to be doing something and hope that everything catches up with us.

Tamsyn Smith: I can see where we're just about out of time and I realise people are probably going to be having to make their way to 11 o'clock meetings. So, thank you very much for all of the questions. I can see there are some we haven't been able to answer in the chat and as Matt and I said we will return to those so that we are able to answer anything that that has been missed but thank you everyone for joining us this morning and hopefully we'll be able to continue the conversations in the JISC accessibility community so thank you everyone!

Matthew Deeprose: Thanks everyone.