<\/p>\n
Both the Kent Academic Repository (KAR) and the Kent Data Repository (KDR) have been around for some time but needed work to improve accessibility.<\/span>\u00a0<\/span><\/p>\n These systems are based on the leading open source\u00a0<\/span>EPrints\u00a0<\/span><\/a>software<\/span>, with a mixture of <\/span>third-party<\/span>\u00a0plugins, in house modifications and styling added. As the software is open source, people can modify it and contribute changes back to community so they can benefit from that work. As a result, many people have contributed to the code base for the repositories. Fortunately, as we can access the source code, we can also amend the code for the repositories to make them more accessible.\u00a0<\/span>\u00a0<\/span><\/p>\n In this post I will cover how we detected accessibility issue, some of the issues we found, how we went about addressing them, and some of the tools that helped us along the way.<\/p>\n We had to look at each component of the system that generated any output to ensure that:<\/span>\u00a0<\/span><\/p>\n As this work was being done, regular te<\/span>sting took place ensure that accessibility levels were improving. Testing with people is one of the best ways to test, but as we need to continuously test our changes, it is a lot of ask people to do the same tests <\/span>over and over again.<\/span> Tools such as\u00a0<\/span>Lighthouse<\/span><\/a>, which is built into Google Chrome, and\u00a0<\/span>WAVE<\/span><\/a> can help by generate lists of prioritised issues outstanding. Hopefully during the process of making a site more accessible, this list should reduce in size every time the tests are run.\u00a0 Testing with users is better done after these automated tests as hopefully most common issues will have been caught.<\/span> A lot of work has already been done by EPrints Services, the commercial company that provides support services for EPrints users.\u00a0Unfortunately<\/span>,<\/span>\u00a0these were mainly to be found in a major new version which we could not upgrade to yet for operational reasons. Instead, these changes were incorporated into our source code by modifying them to work with the version of EPrints we used. \u00a0<\/span>\u00a0<\/span><\/p>\n Further changes were made to\u00a0<\/span>th<\/span>e<\/span>\u00a0our instance of the EPrints source code, each plugin and the theme used<\/span>,<\/span> to meet the goals above. The tools below were used iteratively until improvements were observed. <\/span>\u00a0<\/span><\/p>\n Many\u00a0<\/span>software\u00a0<\/span>tools are\u00a0<\/span>freely<\/span>\u00a0available\u00a0<\/span>to assist in making websites more accessible. Fortunately, there is no need for any expensi<\/span>ve specialist software<\/span>.\u00a0<\/span>Different tools excel\u00a0<\/span>in different<\/span>, so using several tools in combination\u00a0<\/span>was a very useful path to issue discovery and resolution.<\/span>\u00a0<\/span><\/p>\n Keyboard navigation issues were isolated by using the\u00a0<\/span>ANDI bookmarklet<\/span><\/a>. This utility will generate a list of issues with elements that will not be announced by screen readers correctly. It will also show the keyboard navigation by letting you navigate through the screen and showing the label that would be announced.\u00a0<\/span>\u00a0<\/span><\/p>\n The\u00a0<\/span>Accessibility Tab<\/span><\/a>\u00a0in Mozilla Firefox was also used as it can show a representation of the web page with the tab order shown so you can compare it to expectations. Checks were also made by using the\u00a0<\/span>NVDM\u00a0<\/span>screenreader<\/span><\/a> and\u00a0listening to its output to see if it matched expectations.\u00a0<\/span>\u00a0<\/span><\/p>\nProcess<\/span>\u00a0<\/span><\/h2>\n
\n
Improvement approaches<\/span>\u00a0<\/span><\/h2>\n
\n<\/span><\/p>\nSolving issues<\/span>\u00a0<\/span><\/h2>\n