Accessibility

Making every location accessible to every person is quite straightforward. Making computer systems accessible is another matter. Provantage was asked to look at this challenge.

The organisation already had a fantastic attitude towards their employees and visitors who have reduced ability. In fact, they had already won awards for it. However, they had a challenge when it came to their IT systems. It was possible to get special keyboards, mice, and larger screens, but the applications were becoming an area of concern. We would need to look at how each application could be assessed and what should be recorded.

Getting accessibility statements for COTS products is fairly simple. Although accessibility is mainly voluntary, most software vendors appreciate there will be users who might not be as able as others. On the surface, the problem didn’t appear to be too much of an issue. After speaking to senior and section management, two trends emerged.

The first was recruitment. The organisation had no bias against people with disabilities and had a good track record on supporting them. However, recruiters would get a very strong candidate for a role, but would not be able to take them on if any of the systems couldn’t cater for their impediment. But because they didn’t have a good view of the systems involved, some incidents arose which resulted in litigation.

Next, there are employees who have sponsored career paths. These are new starters who have showed potential to become the next C Suite executive. For them to be effective, they need to go into a set of departments to learn the trade of the business. If they had a disability that would require adjustment, they could be prevented in reaching their goal, and this raises the risk of further litigation.

The organisation needed to get a better grip on what the accessibility position was on all its systems.

Our approach was to break down the different types of disability: physical, hearing, sight, and neurological. There could be combinations of any. This allowed us to ensure all physical disabilities were catered for by Occupational Health, which most were. Adjustments to workstations, offices, car parking, and social areas were well maintained.

This left the problem of accessibility to the software and systems for people with sight, hearing, and neurological issues. This is where we started looking at the roles and ran a series of workshops to determine the level of health needed to fill them. For example, if the role involved a considerable amount of driving, then this could be open to someone with significant hearing loss, but not to someone with significant sight loss. Similarly, a drone pilot must have good eyesight and good hearing to enable them to listen out for calls, messages, or to listen to changes in the drone’s motors which could signify a problem.

We drew up a matrix of each role and scored the ability needed for each person between 1 (full ability needed) and 5 (role open to a person with significant impairment). This became an important artefact when planning a new starter or someone on a sponsored career path.

Using the organisation’s business map, we were able to determine each application used by the role. From this, we were able to determine which applications needed to be assessed. In some cases, an application was used by a role which needed no disabilities, but was used in another role which could be performed adequately by someone who had significant sight loss. Where these overlaps occurred, a full assessment would be required, even if there were no people in the second role with any sight issues.

We created an accessibility policy for software. This was accepted by the development teams that enabled them to think about accessibility from the beginning. Testing processes would include assistance software and determined the compatibility level.

Existing systems were tested with assistance software, and the role/application matrix updated to show how compatible they were with users with specific difficulties. This showed gaps where assistance software alone wouldn’t be enough to allow disabled users to get full value from the system. For example, geospatial software is highly graphical and as such doesn’t lend itself to visually impaired users. In these cases it wouldn’t be possible for sight impaired new starters to work in that role. However, for employees on sponsored career paths, it would be possible to have someone sit with them and read what was on the screen, as the time in the role is time limited.

The common thread throughout the accessibility policy was ‘reasonable adjustment’. One example is if it was going to add six months and several millions to a development to make it accessible for everyone, then this is clearly not a good strategy. Instead we convinced the organisation it it was a better strategy to declare the level of accessibility on the accessibility statement. This would have been seen as carte-blanche for developers to skip any sort of accessibility testing, and simply declare their software is not accessible. They can do this, but only when they provide comprehensive documentation proving they have done an acceptable level of testing.

The accessibility policy determined what a development team were expected to do and where the boundary was that suppressed any nugatory testing such as accessibility for people with sight loss on software that will be used to control a drone, or highly graphical systems.

Accessibility is baked in at the point of development, rather than it being an irritating add-on later.

Employees with disabilities could communicate problems, missed applications, and difficulty using certified accessible systems.

The accessibility policy, updated to include software, is fully understood across the organisation.

The role/application matrix, populated with accessibility scores enabled better planning for new starters, who immediately knew what was needed and where.