We\u2019ve found that it\u2019s nearly impossible to build accessible websites without testing them out in some way. We never assume we\u2019re going to get everything right first time, and maybe not even the second time. It\u2019s a process of honing our skills and adapting to changing needs and technology.<\/p>\n
Testing our websites<\/h2>\n
Our colleagues in Project OPERA<\/a> have done a huge amount of work to thoroughly test a range of University of Kent webpages: prospectus pages, academic school websites, staff profile pages, and main navigation areas of the template.<\/p>\n They invited three people – two impaired vision users and one screen reader user – to follow a set of general instructions for which areas of the website to navigate to and around. They weren\u2019t told how to navigate the sites, simply what kind of information to look for and browse.<\/p>\n These tests have given us really useful, detailed information about where we had significant weak points. Our thanks to the Project OPERA team for making such detailed records of these users\u2019 interactions and feedback!<\/p>\n In fact we\u2019ve now started to test our sites with screen readers ourselves. This is particularly useful where we need to get some initial idea of whether a fix might work in the real world rather than just a theoretical improvement.<\/p>\n Using screen readers and assistive technology isn\u2019t at all easy, so testing ourselves has limitations. It\u2019s technically quite a steep learning curve, and we\u2019re never going to fully replicate the kinds of experiences a blind or visually impaired user will have.<\/p>\n For example, we\u2019ve found that screen reader users typically approach navigating websites in quite different ways from sighted users. It\u2019s not just that screen reader users conceptualise the structure of the page differently, but the whole approach to interacting with websites differs. It can often be more detailed, more systematic, and much slower.<\/p>\n Impaired-vision users also have needs which can be all too easy to forget about. For example they may often rely on large amounts of page magnification which can make related elements on the page less obvious. The space that we designers tend to add to pages to help create a degree of cognitive simplicity for many users can actually cause problems for some.<\/p>\n We found the feedback could be broken down into a few key problem areas. We\u2019ve already managed to fix some of these problems, while others are in progress. Some are harder to fix because they\u2019re caused by code that we\u2019re using from other libraries. But at least we\u2019re now aware of the scope of these problems.<\/p>\n We found it wasn\u2019t always clear that main links on feature panels were actually links, and not just text. We thought we\u2019d given enough of a visual cue with a chevron next to the text, but to some users this wasn\u2019t particularly obvious. We have considered whether it would be worth adding some kind of underline to these links instead. We\u2019d like a bit more feedback on this before making what is a fairly major design change.<\/p>\n <\/p>\n We found for some users that breadcrumb text didn\u2019t have enough contrast, so we\u2019ve increased this.<\/p>\n We discovered that a big problem for screen readers was that while users could navigate to areas of the page easily enough, they couldn\u2019t necessarily tell what the purpose of that area was.<\/p>\n A good example of this was a search filter box which to a screen reader appeared as \u2018Course filter\u2019. What it controlled and what it was there for wasn\u2019t at all clear.<\/p>\n These sorts of issues are easily fixed with A critical problem in our website for screen reader users was our course search box. This was so bad that one user said they\u2019d give up and call the university to find out more. Given that prospectus pages are a key part of our website, we needed to fix this as a priority.<\/p>\n We found that the problem was actually with how the autocomplete on the search box wasn\u2019t providing screen reader users with appropriate feedback, or any means to know where the search results were being displayed.<\/p>\n It\u2019s worth noting that during the original development we\u2019d taken pains to make this autocomplete accessible. This is a great example of how following guidelines and code samples is good in theory, but if you don\u2019t test with real people you can easily end up making things worse.<\/p>\n We had some issues with both our carousel panel and virtual tour panel.<\/p>\n Sadly both the carousels and virtual tour rely on 3rd party code. For now there doesn\u2019t seem a lot we can do to improve the situation. However we are now investigating replacing these libraries with better ones.<\/p>\n Videos presented a range of challenges.<\/p>\n One of the key problems was with our video feature panels. These have a large image and a \u2018play video\u2019 button. Only when the user clicks the button will the video load in a modal box.<\/p>\n For screen readers the image just seemed to be an image, and the play button was invisible. So the end result was that screen reader users never realised they could load a video.<\/p>\n We fixed this by making sure the overlay which loads up the video is clearly marked as something that will start a video. We did this with Another problem with videos was that while we\u2019d provided a link to a transcript, this link wasn\u2019t very prominent. We moved the transcript link above the video and made it more visually prominent.<\/p>\n We also found that YouTube videos in a popup can\u2019t be closed with the ESC key once they\u2019ve been played. This is true for sighted users, but sighted users can easily click away from the popup, or can click the close button. We haven\u2019t yet fixed this bug, but we\u2019re working on a solution.<\/p>\n Finally, we encountered a problem where the video popup allowed screen readers to interact with content \u201cbehind\u201d the modal even when the video was still open. We fixed this using the One interesting thing we found in our feedback is that for all users, having information on one scrollable page is preferable to having separate tabs which load in the information separately.<\/p>\n For example, users preferred the way we\u2019d organised our staff pages (information all on one page with anchor links to relevant areas) as opposed to our prospectus pages where users have to click a tab to load up a new section of information.<\/p>\n The reason seems to be simple: the more information there is about a topic on a single page, the easier it is to search and move through, and the easier it is to make sense of links in the content.<\/p>\n We got a lot of really useful accessibility feedback about our site, even from only 3 users. We found a range of bugs and issues, including accessibility problems with labelling, search, and videos. This work has encouraged us to try using screen readers ourselves more in future, and rely less on official guidelines and more on the reality of using websites with screen readers or zooming into the page.<\/p>\n","protected":false},"excerpt":{"rendered":"Self-testing with screen readers<\/h2>\n
Feedback from testing<\/h2>\n
Readability<\/h3>\n
![\"screenshot](\"https:\/\/blogs.kent.ac.uk\/webdev\/files\/2018\/12\/Screenshot-2018-12-07-11.35.27-1024x264.png\")
<\/a>Screen reader labels<\/h3>\n
aria-label<\/code>, aria-labelledby<\/code> and aria-controls<\/code>. We found that by simply being a bit more thorough with labelling items such as navigation areas, menus and search boxes we added a lot of value for screen reader users.<\/p>\nSearch autocomplete<\/h3>\n
Carousels and virtual tours<\/h3>\n
\n
Videos<\/h3>\n
aria-label<\/code> and aria-controls<\/code>.<\/p>\n![\"screenshot](\"https:\/\/blogs.kent.ac.uk\/webdev\/files\/2018\/12\/Screenshot-2018-12-07-11.45.29-1024x462.png\")
<\/a>aria-modal<\/code> attribute, which tells screen readers to keep focus on the popup\/modal. If you\u2019d like to know more about getting popups and modals to work with screen readers check out the excellent blog post The current state of modal dialog accessibility<\/em><\/a>.<\/p>\nDon\u2019t use tabs<\/h3>\n
Summary<\/h2>\n