How can we integrate the goals from our accessibility policy within other departmental processes? We’re aiming to spread the responsibility and ensure that accessibility is considered as an integral part of day-to-day activity. Considering the cost of bugs, the sooner we find them the less they cost to fix. And 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. In other words, if we say “only release when it’s accessible” or at least, assign responsibility and make a plan for resolving accessibility defects, include accessibility within requirements, and testing. Then the teams who design and build new solutions know that accessibility is expected. There are many possible options already 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. Where frameworks are used, the accessibility of their native elements such as colours can be verified, here for example are the default colours used by bootstrap, some of which have insufficient contrast. Axe linter will automatically request changes to resolve common issues from pull requests in github. Automated accessibility testing can be included in continuous integration practices. There’s an excellent demonstration of this by Mark Steadman from Deque available to learn more on YouTube. 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. An interesting example at the University of York is a group of student screen reader testers. In her presentation “Auditing Design Systems for accessibility”, Anna Cook shares how the principles set out by Brad Frost in his book “atomic design” can help us to review our design elements for accessibility. Every University is likely to have a brand with colours, fonts, and other design “tokens” that web developers use when building “Atoms” such as dropdowns and buttons, which are then put together as components or “Molecules” and Organisms, which are then applied into templates and pages. The accessibility of these can be tested and remediations made, so that a component library can be built up. For example, when you know all the colour combinations in your brand that have sufficient contrast, you know these are now your available options and can discard the others. These practices help us to ensure accessibility is built into our components, it does not remove the need for accessibility testing but should mean that simple aspects like forms and colours are no longer frequent accessibility issues. 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 for to prioritise accessibility, and include accessibility within non-functional requirements.
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 been using is presented in a more waterfall style format, this is just as applicable in Agile.  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. On screen is the html and javascript to create a button. On the right, the semantic button element is used, on the left the same is achieved without using semantic elements. Much more effort is required to make this “button” keyboard accessible. You can view the demo for yourself on CodePen.