Transcript: Sustaining accessibility efforts through accessibility-related appraisal objectives

• Presentation recording
• Presentation resources

Tamsyn Smith: Excellent. Thank you very much, Ben. Well good afternoon, and as Ben said we're here to talk about accessibility-related appraisal objectives which is a piece of work that we have recently started at the University of Southampton. I'm Tamsyn Smith, I'm Senior Learning Designer Team Lead at the University of Southampton and I'm joined by Matthew Deeprose, he's a Senior Learning Designer. So, over to you Matt.

Matthew Deeprose: Hi everyone! Thanks for inviting us to join you today on Global Accessibility Awareness Day. As Christian Bale says in the film Terminator Salvation, "if you're listening to this you are the resistance".

It often feels that those of us with an interest in accessibility are part of a resistance aiming to reduce and remove inaccessible practices and unnecessary barriers that prevent people from making the most out of the potential of our digital estate.

No doubt many of you have experienced advocacy fatigue. Pointing out simple issues like focus indicators, focus order, colour  contrast, alternative text for the umpteenth time can wear you down! But we want to move from resistance into the mainstream. We want everyone to care and be interested and we want considering accessibility to become second nature.

In this session, we're going to talk a little more about this context. We appreciate that our presentation may be of more interest to the "accessibility geeks" among us, so we're going to use this context section to try to give some pointers to useful resources for those new to this area. We'll then share our early thinking of an idea we're developing aiming to embed accessibility more into the culture of our IT department through creating accessibility-related appraisal objectives for a variety of roles. And then talk about some next steps, share with you the work we've done so far, and invite you to share feedback and build on this early work.

The slide deck, links, and resources that we cover in this session are online and we'll be pasting this in the chat. Maybe Tamsyn will be kind enough to paste that link in for me. But it's also… if you scroll up in the chat you should see it there as well if you could see the chat history.

Every institution is at some point in its accessibility journey. We work in the University of Southampton IT department and to give you an idea of where we are at: whilst we don't have an IT accessibility policy, accessibility conformance is part of our "Non-Functional Requirements" for procurement of new services. We have accessibility knowledge and skill as requirements for developer roles. We don't have accessibility testing as part of our change and release process and are not measuring nor reporting on accessibility. We have a fairly well-established accessibility Community of Practice, but we don't have an established accessibility testing process, nor training specific to different types of role. We do have buy-in for accessibility from our leadership group to some extent at least.

So what does that look like for us in our IT department? First, we can only talk from our own experiences and what we see.

On the positive side we have seen our internal digital accessibility community of practice grow to include about 20 percent of our department as members. Through introducing Blackboard Ally in the educational context, we've raised awareness of accessibility further even within our own IT department. We find ourselves receiving ad-hoc requests and enquiries relating to accessibility; showing that some are realising this needs to be considered. Of course, it's coming towards the proofing stage rather than " shifting left" to the initial requirements and design stages.

On the other side, without checking for accessibility as part of our change and release process, new IT services are being launched with accessibility issues that are not logged or prioritised, building accessibility debt that will have to be paid off later - with interest. Like many institutions, we received our letter from the Central Digital and Data Office for not meeting our responsibilities under the accessibility regulations. Whilst a lot of the issues identified were already on the roadmap for improvements to our corporate site, thanks to a massive transformation project led by our colleague Ayala Gordon, we had hoped it would start a wider conversation in our IT department about how to avoid introducing such issues across our whole digital offering. For the moment it seems that very few in our department are aware that the government has contacted us about this. We need to acknowledge initiative fatigue. Our colleagues have been through a lot over the last few years. Now we have new strategies, new initiatives, and the same amount of time to get everything done. Telling people, "here's more work you've not got time for" is not going to go down well, however well-intended.

On the topic of 'more work', I always like to refer to this tweet. "Accessibility isn't more work, you were just cutting corners before. The work was incomplete." This is particularly relevant for a professional IT department.

You might hear people in the accessibility community talk about sustaining accessibility. It's the fourth point on the Planning and Managing Web Accessibility pathway from the World Wide Web Consortium (W3C). Here, sustaining accessibility is about maintaining the momentum of our accessibility efforts.

Looking at another framework, Lillian Joy at the University of York has done some brilliant work demonstrating how Kotter's Eight Steps can be used as a framework for shifting digital accessibility practice. The last of the of these steps is about anchoring changes in corporate culture. So, embedding a change in departmental culture is obviously really important. If you'd like to learn more about Lillian's work you can watch her presentation to the JISC Accessibility Community in a recorded webinar and read more about it on the University of York website

Continuing our thoughts about culture, Craig Abbott from the Department of Work and Pensions has recently published a blog post sharing his three pillars of accessibility. He writes that, "There are 3 core parts. Compliance, education, and culture. If you lack any of these 3 things over a sustained period of time, the strategy is unsustainable and your ability to consistently deliver accessible services will burn out". That mirrors Kotter's eighth step. On the topic of the DWP it's worth looking over their accessibility manual which is a really useful resource. They have a section that relates accessibility to different job roles , which also aligns with some of the work we'll be talking about shortly.

Back to the context! Now, as George mentioned on Monday's session, accessibility skills are in demand. While Teach Access found that very few university tech programs include accessibility, the Partnership on Employment and Accessible Technology (PEAT) did research that found that 63 percent of tech companies were unable to staff their accessibility needs and 93 percent expected that demand for accessibility skills would increase. Last year the Wall Street Journal wrote that accessibility job listings had increased by 78 percent.

So, accessibility skills are in high demand. Universities tend to have a lower turnover than the private-sector, we will face the need to keep up that pipeline of maintaining staff with good knowledge of accessibility, which again will reflect into our organisational culture.

On that topic, there's some resources to be aware of. Teach Access provides an accessibility skills hiring toolkit and Scott O'Hara has created a list of accessibility interview questions for different types of roles. The W3C provides a framework for building your own accessibility training courses and Teach Access has a tutorial aimed at developers that covers some of the basics. For generalists, Microsoft have created an Accessibility Fundamentals learning path and Hector Minto from Microsoft has a very practical LinkedIn Learning course about accessibility in the modern workplace. For educators, Lexdis has a very useful online course for inclusive teaching and learning strategies.

We need to reach out across our IT organisation to build that culture and awareness. I'm sure many of you will have encountered colleagues thinking accessibility is about identity management and service access. It's a recurrent theme in our department to have to explain what we mean by accessibility. For example, a database manager recently told us, "My job is to make things as inaccessible as possible". In discussions with our communication platforms manager, he said he hadn't ever tested the corporate site platform for which his team is responsible with a keyboard.

So, when we talk about sustaining accessibility, we're thinking about how to keep momentum even without a formal accessibility policy (that we're missing at the moment for ourselves) we can increment further by building an organisational culture that considers accessibility.

Tamsyn Smith: So, what opportunities are there each year? Most institutions are likely to run annual performance reviews with staff reflecting on the past year's outcomes and setting objectives for the year ahead. You might call these appraisals, personal development reviews, or something else. Typically, no one enjoys writing objectives.

So, what if we could give people some ready-made objectives, designed to raise awareness and understanding of accessibility in the IT department, and helping to create that organisational culture? 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. We're based in our IT department but these principles can be applied elsewhere as well.

So, the idea is to create a "bank" of accessibility-related appraisal objectives. That can be used "as-is" or customised, and are appropriate for different types of role. We've been focusing on generalists, developers, and system support roles. At different levels of accessibility awareness and skill, suitable for whatever stage an individual is at, ultimately aiming at steering towards the "partnership" level of maturity identified in the McNaught / AbilityNet accessibility maturity model.

We've broken them into different types of IT role. First those that apply for any role, so universal or generalist. Then developers will have certain responsibilities for accessibility, and also have knowledge of accessibility as a requirement in their job descriptions, so we need something for them. We have a large number of application support specialists who are answering tickets, planning upgrades, writing documentation and so on. They're also responsible for roadmaps for services so we need to consider something for them. Then there are other roles like business analysts, project managers and so on who may be dealing with vendors, planning out projects and they might have a small number of objectives specific to those certain other roles.

Then we have four levels or stages. We start at "general awareness", moving on to "discovering", focusing more on applying knowledge, building skill and exploring potential for improving accessibility within a colleague's area of influence. Then moving on to "exploring", aiming for a deeper understanding of accessibility and its potential application and asking colleagues to collaborate with users with impairments and disabilities, and then finally moving on to "advocating" or "championing".

By the way, the American company Intuit has an accessibility champion program that also has four levels. If you haven't come across it before we recommend Ted Drake's blog post that explains how it works. He lists lots of different tasks for those at each level and there's lots of great ideas in his blog post

Here are some examples of different types of high-level activity included in these objectives. We've mixed in objectives for different role types. At the first level of general awareness, we have basic training. We have a generic training resource and links to further content on LinkedIn Learning and Microsoft Learn as well as those resources from Teach Access and Lexdis that Matt mentioned earlier. We've got reviewing vendor Voluntary Product Assessment Templates or VPATs and accessibility roadmaps or local accessibility statements to find out how what you learn in the abstract applies directly within the services you support. And observing how your team culture, for example online or hybrid meetings, reflects inclusive practices and suggesting improvements. As you learn some of these basics it might be interesting to see how they apply in activities like team meetings.

Then at the discovering level, you might be learning how to run simple accessibility tests perhaps based on the W3C's easy checks. Or creating or reviewing an accessibility statement. I know we have hundreds of [accessibility] statements that need writing and Ben at UCL is doing some interesting work on making this process easier. Accessibility can be really daunting when you're new to it, so prioritizing accessibility defects can be a good way to identify what's important to fix first and perhaps to start thinking about how to avoid such issues in the first place. The Agile Accessibility Handbook has an excellent methodology for prioritising accessibility defects.

Moving on to the exploring level, working with service users who have an impairment or disability. This could be in terms of understanding current issues, consulting on new developments, or learning about assistive technology use, or examples of barriers that they face. For developers refactoring a component to fix or improve accessibility issues whilst maintaining functionality should lead to learning opportunities for understanding better how such issues were introduced in the first place and lead to thinking about stopping them from reoccurring.

Then finally for advocating or championing, we're thinking about moving beyond the team level and talking to others perhaps even outside the institution.

We mentioned the Agile Accessibility Handbook in the last slide. If you've not read this book, it's a very practical guide to implementing accessibility within an IT department. It's less than 100 pages and the electronic version is available free of charge. I think Matt just posted that in the chat.

The structure of our draft document has got four parts: a title, we've only been sharing some example titles so far, then the category aims to match with one of the three categories for appraisal objectives within our HR system, then the description is meant to be a SMART objective, so Specific Measurable Achievable Realistic and Time-boxed, and then lastly 'what you might do to achieve this', is more open and suggestive. So far, it's been difficult to differentiate the description and the 'what you might do section' so we may revise those

The idea is not just to do the activity but to do it for a reason and having the outcome feedback into the team or department in some way, hopefully then building a virtuous circle. For example, discussing a service your team supports with a user who has a disability or impairment, in order to identify what works well or not so well, and then gain a better understanding of the types of barriers the user faces, with an outcome of developing an action plan to improve the user experience and discuss that with the team, business owner, or user community

So, your turn! We're going to pause and give you the opportunity to take part. In the next three minutes why not think of an example action using this template. First you will describe a role and a level of accessibility awareness. Then you'll suggest an action and describe its outcome. Then add in how it will feed into a team activity.

So, I have an example. As a person wanting general accessibility awareness, I will turn on accessibility checking in Microsoft products, in order to identify and resolve issues as I work, and then with my team we will share experiences, lessons, and tips.

So, we'll give you three minutes. Please post your suggestions in the chat and even if you don't have time to finish keep a note of what you've done because we're going to return to it later. While you work on this, we'll check if there's any questions in the chat. So, we'll just have a look and see if there is anything that's there.

Matthew Deeprose: Brilliant thanks Tamsyn! So, everyone, hopefully you've got an idea of what we're asking of you. I'm going to start a timer and give you three minutes of time, but we will be kind of burbling on in the background perhaps anyway. If you're stuck for time, or you just can't think of anything now, just keep this in mind because we'll tell you how you can work with us on this later. So, I'm just going to start my timer for three minutes.

Now let's just have a look through the through the chat. So let's see. Ben [Watson] said "looks like we've been reading his mind", which is fantastic, and I hope not just that you were thinking that we're in the apocalypse trying to make our way through a world controlled by machines, but more in terms of the feeling of being part of a resistance and trying to make things better!

I'll just continue just checking out what was in the chat. So, Ben, again thanks for contributing, you mentioned that someone very senior in a large public sector body in the past said, "accessibility means making stuff available on your website 24/7, doesn't it?" Then Mike (Wald) added "it does, but we need to add 'for everyone'", which is incredibly relevant of course.

I think that we've exhausted what was in the chat. Ben it's up to you and I to fill in, and with Tamsyn, to fill in the next two minutes. Well, hopefully some of our attendees are making some notes of some of these ideas: "as a…" and then a role and level of accessibility knowledge, "I will…" so think of an activity in order to achieve some kind of outcome, and "then with my team…" we're going to then feed in and use that information in some way. So sorry, I interrupted you Ben go ahead.

Ben Watson: I was just going to say I had a quick go. I was completely inspired by this, and I thought would it be good for me to share that now as a quick example?

Matthew Deeprose: Yeah, go for it!

Ben Watson: As an academic, I will always wear a microphone, in order to ensure captions are as accurate as possible, and then with my team we will share the outcomes of this to encourage other people to do the same.

Matthew Deeprose: Brilliant! I love it! That's fantastic! This is really good.

Ben Watson: It's one of the things that always comes up, so it's very near to my heart that one.

Tamsyn Smith: We've got a lovely example there from Claire [Robertson] as well. Thank you, Claire. "As a college disability tutor, I will turn on an alert encouraging students and staff struggling with digital accessibility to outline what they're struggling with, in order to understand what the challenges we need to tackle are, and then with my team we will tackle as many things as we can to improve this". Thank you, Claire.

Claire Robertson: And then I would love to see, as a partially deaf academic, I wish so many more people would wear a microphone because it can be really tough! So that's a great goal.

Ben Watson: Thank you. I think, you know, because there's lots of talk about captions and the kind of time pressures of correcting captions and I think you know that's for institutions to discuss about where the responsibility for that ultimately should reside, but I think getting people to meet people halfway by wearing a microphone, not turning their back, explaining acronyms they're using, repeating questions from audience members, there are so many things that can improve the chances that the automatic speech recognition has.

So, I think things like this and building it into appraisals is just brilliant because I think there is definitely an initiative fatigue a bit, possibly like there was with GDPR. Everyone got very excited about it for a time and then the deadline came and it seemed to fall off a cliff a little bit. So, I'd hate that to happen here. I think setting goals that people have to achieve year-on-year as part of their appraisal kind of makes it, I don't know, a bit more meaningful doesn't it? And therefore, it's not just the people who are interested, the people who are the accessibility people doing this, it's kind of everyone's responsibility and I love that.

Matthew Deeprose: Great point, and Mike [Wald] has pointed out that with the move back to the classroom, that's meant a lot of people have experienced a loss of sound quality and captions. I've even heard some people just stop recording their lectures because they don't see it as a priority or something they need to do now that supposedly things are "back to normal" which is quite disappointing. Again, having an institutional policy or perhaps even taking that decision away and just automating that the recordings will start at this timetable slot and so on… but I know there's challenges with those types of things as well.

And Mike also suggested that accessibility should be part of promotion criteria, and I think that's very relevant as well.

Ben Watson: Could I say I think it should also be part of Teaching Excellence Frameworks. I can't believe that you can get Gold for something and you're not necessarily providing for all of your students. I think that's… you know and I think this model, we could absolutely share more widely and seek to get this built-in… definitely to promotions, but definitely into things like the TEF as well as you know that that would get Vice Chancellors interested I imagine.

Matthew Deeprose: Definitely! And our brilliant colleague Sarah [Lewthwaite] from the education team, or the education department at the University of Southampton has put one in: "As an academic, I will introduce VPATs (that's voluntary product accessibility templates) as a tool to colleagues in research, in order to promote inclusive digital procurement for research conferencing etc, and then with my team I will evaluate progress and challenges / pinch points and…", some great chat coming in that it just scrolled away from my eyes so, "…and then with my team I will evaluate progress and challenges / pinch points to build on this knowledge". That's fantastic!

And Ben, do you want to talk about what Mette had said on Monday about the Going Back is not a Choice launch?

Ben Watson: Well I just think you know, going back to Mike's point about this worrying kind of roll-back to physical modes of delivery, and seemingly forgetting all the brilliant stuff we learned during the pandemic and all the progress we made… that one tiny ray of light, well a huge wave of light from a really awful experience, was we made some really excellent progress and not just for people with disabilities. I think universally for everyone in terms of, you know, home working and just being able to access learning with a choice and I think it's such a shame if we switch off some of the things that gave that choice to people. So it was just a reminder that Mette who is behind the Disabled Students UK report spoke earlier this week very powerfully about that and the impact of that and I think that's for anyone who wasn't able to see that please check back the recording and read the report because it makes that case very powerfully, why we mustn't switch that stuff off.

Matthew Deeprose: Definitely, definitely. One last one before we will carry on with the presentation. Alison [Ormesher] has written, "As a learning designer, I will use the accessibility checker when creating Office 365 materials, in order to highlight anything I may have missed, and then with my team I will ask for suggestions of fixes to the things I don't understand". One thing earlier today, I gave a presentation about writing alternative text for complex graphs and images and just through learning about that showed me how deep you can go with writing alternative text and full descriptions. So, I think that's a really nice way - feeding back with the team… especially learning designers might encounter lots of complex images for which they're not the subject matter experts and needing to understand good approaches to working with those subject matter experts to write that really good, relevant, contextual alternative text.

I see Leon…

Tamsyn Smith: One more there Matt, Leon [Campbell] yes I think you just picked that one up.

Matthew Deeprose: I'll let you read that out, yes.

Tamsyn Smith: Leon's one, so, "As a member of staff with a particular interest in digital accessibility, I will keep learning about how to make everything [available] accessible to all, in order to allow anybody to access any information and or material, and then with my team we will work together to increase our ability to learn about and further recognise the needs that exist especially those which are not being addressed". So, yeah another good one, thank you very much Leon.

Matthew Deeprose: Yes, thank you Leon! Right! We're going to continue with the presentation, but don't worry we'll have further discussion opportunities after this next chunk. So, I think Tamsyn I'm continuing from here.

So, okay… So, now we've got some more examples of objectives at the general awareness level, separated by role type. Now, these are just high-level on this and the following slides, and we're just showing the starting point which is why each line ends with "and…".

So, for everyone, we have a basic level training course. We don't want people just to complete it but to reflect on what they learn and discuss it in a team meeting, or with a colleague, and perhaps reflect three months later on how what they learned affected their day-to-day work.

Developers in our IT department are expected to have knowledge of " modern HTML, CSS and Javascript and its impact on accessibility". [Clears throat] Excuse me. It's in their role's person specification, so they should be starting at a higher level already.

There's a useful tutorial on teach access that we showed you earlier to refresh the basics. We might want them to reflect on their experiences already from having that knowledge, perhaps in the form of a presentation. It doesn't have to be a good experience. We can learn a lot when things go bad or wrong as well.

For support specialists, it's important that they understand to what extent the services they support meet accessibility guidelines because they tend to be the service owners. So, understanding VPATs, accessibility roadmaps, and statements is a good start, especially replicating errors or validating the truthfulness of these statements, because would you believe, sometimes the VPATs are not 100% accurate. Just doing these exercises is likely to lead to discoveries that can be fed back within the support team and to the vendor, be they internal - like we internally develop something, or external as a commercial solution.

Here's some level two examples again at that high-level of detail. Here we're at the discovering stage.

At the generalist level, we want people to become confident using accessibility checking features in office and resolving defects in content.

For developers, we wanted to go a bit deeper into testing starting, with the W3C's quick checks. It can also be useful not only to learn about some success criteria from the Web Content Accessibility Guidelines but you can get a deeper understanding by studying the sufficient techniques: those are examples of how to meet certain success criteria provided by the W3C in the Web Content Accessibility Guidelines. So, we might then ask for them to give a demonstration or presentation to colleagues at a team meeting and then lead a discussion.

Support specialists could start reviewing their support guides and documentation and revising those for accessibility, for example using semantic ordered lists for step-by-step guides and using "select" rather than "click" within written instructions. For commercial off-the-shelf services, VPATs should help make writing accessibility statements fairly straightforward. Again, they should be feeding back lessons to their teams and feeding forward to vendors and so on.

Here's a light overview of some level three, exploring, objectives.

We might ask generalists to reflect on their own working practices and behaviours and look for how small changes may result in more accessible or inclusive outcomes. We might also ask developers or support specialists to work with staff or students with disabilities, observe how they use the services for which they are responsible, and talk through potential improvements or promote how assistive technology works with a university service. Most of our support specialists have never tried to use a service that they own with a keyboard or screen reader. So, all these are high-level just to give you an idea and obviously these are not written out as smart objectives.

At the final level we're looking for people to share their lessons, good or bad, with the wider department or external audiences, building up that organisational culture. Pair programming, where a developer with more accessibility experience works with another developer, can be a good way to work through those accessibility puzzles I'm sure we've all encountered in our time. Building on partnership, support specialists by this point should be building a close working relationship with staff and student groups.

Pair programming has been recommended by Mark Steadman, who is the principal accessibility engineer at Fidelity Investments. Last year he tweeted, that he found, as an accessibility consultant, that sitting with developers and creating a component together is a great approach and learning opportunity. By the way, make sure to read his award-winning posts on the dev.to website.

In terms of progress, we have a first draft for about two-thirds of the initial content we planned, and we're slowly working our way to completing that final third of the first draft. This is all going to need to be reviewed and quality checked, then confidence checked with a wider circle of colleagues. Assuming we get the go-ahead, we will then publish internally and begin raising awareness. Hopefully, we'll get lots of feedback and ideas for next steps so we can monitor progress and iterate further.

Tamsyn Smith: As you can imagine, it has been a challenge. After an initial sprint of activity our pace has slowed because writing objectives is hard! We also don't know for sure whether there will be take-up, but we think that since writing objectives is hard, if we can give line-managers some quick wins then these might be popular. We're not sure yet how we can objectively measure take-up and outcomes: obviously appraisals are confidential between a direct report and their line-manager. We're also going to be talking more to our disability staff network and student groups to ask for feedback on these ideas, we're particularly concerned to get buy-in from them and not end up with our colleagues randomly asking the same groups of people for similar feedback.

On the plus side, we'll be sharing a draft of the work that we've done so far, and once we're complete we're going to be sharing this work through Creative Commons to the accessibility community. We've had a couple of managers in our department who are already showing interest, and accessibility contacts we've spoken to so far all see a lot of potential in this concept.

So what's next? Well, we've written the first drafts of almost 40 objectives so far. We've made them available as a google doc. You're welcome to download it, view it, add comments, make edits, or make some suggestions but please keep in mind it's still an early draft and a lot more effort is needed to make these of acceptable quality in terms of them being SMART, and in confidence checking that they should achieve the desired outcomes. We think a document probably isn't the best vehicle for this information but when we make it more widely available, we expect to share it on GitHub with a Creative Commons license. Why not develop your idea from earlier, we obviously saw a lot of those in the chat, and consider writing it up into a SMART objective and adding it to this document.

Thank you very much for listening to Matt and I today. We're happy to open up now for any discussion.