Accessibility is extremely important to the Doc Ready team, so we were keen to take this into consideration from the outset of the project. All too often we see projects where accessibility is seen as an afterthought or a “nice to have” and this is exactly what we wanted to avoid. Our team of designers and developers have worked hard to make Doc Ready as accessible as possible in the time available to us.
Of course, nothing can be truly accessible to everyone, so we hope that the considerations taken into account (listed below) have addressed a wide range of people’s needs. Everyone has different needs and wants, so Doc Ready’s accessibility features can be supplemented by browser / device customisation to help tailor this further to the individual. AbilityNet’s My Computer My Way is a good resource that explains the accessibility features and settings (vision, hearing, motor and cognitive related) available on computers to help make them easier to use.
Read on to find out more about Doc Ready’s accessibility:
What good is a web page if you can’t read it?
One of the easiest ways to make a site inaccessible is by using a font size that is too small. Over 2 million people in the UK experience some form of visual impairment, so using clear typography at a generous size is a no-brainer.
In Doc Ready, the body text is set to 16 pixels, which should make reading the screen text similar in ease to reading from a book for most users. All web browsers set text to 16 pixels as a default (minimum) font size but web designers have a habit of trying to reinvent the wheel and often opt for a smaller font size to save space.
The article 16px Body Copy: Anything Less Is A Costly Mistake, makes a good case for why this intervention should be avoided.
Some users will find 16 pixels still too diminutive and are welcome to use their browser’s zoom function to increase the font size further. The easiest way to do this is by pressing CTRL and + together.
Web pages that have a “fixed” design become problematic when zooming because the design starts to get bigger than the screen, obscuring some of the text and imagery. Because Doc Ready is flexible, as the text gets bigger it reconfigures (or “wraps”) to fill the screen appropriately. This type of flexibility is often referred to as “responsive web design” because it makes the content “responsive” to the space that is available.
It is this design technique which also allows Doc Ready to be usable on different screen sizes, from Desktop monitors to different phone handsets.
In web design, the subject of contrast typically relates to the relationship between text colour and background colour. For instance, white text on a yellow background could be considered a combination that is too low in contrast to make the text easily legible. This is why we made the decision to change the text on the “advice” navigation link from brilliant white to a dark grey, as illustrated below.
Contrast becomes a more complex concern when you consider users who are affected by colour blindness, which accounts for approximately 4.5% of the UK population. While most users can rely on both hue (colour) and tone (shade) for contrast, some users will see little difference in terms of hue for certain colour combinations and have only tone to fall back on. For instance, green text on a red background of a similar tone may be readable to some but the text becomes almost invisible to others. The best way to test is to take a screenshot and convert it into a greyscale image in a photo editor like Photoshop. The result is often surprising! In the case of Doc Ready, we have tested for contrast but please contact us if you are experiencing difficulties in this respect.
Using the keyboard
It is easy to forget that not all users of websites and apps click on links and buttons using a mouse. Using a keyboard instead to navigate a web page is quite a different experience. Sometimes users experiencing neuromuscular conditions or tremor have no choice but to rely on keyboard controls because they are not able to achieve requisite accuracy when trying to point the mouse at objects on the screen. For the most part, such users will harness the TAB key to jump from one control to the next. When one of these controls has been “jumped onto”, it is said to be “focused”.
However, it is difficult to lose track of which control is “focused” unless it is visibly highlighted. Focused controls in Doc Ready’s “advice” section, for example, switch to a dark blue colour. This way, keyboard users have some indication about which subsection they will be opening when hitting the ENTER key.
Most HTML elements (or “tags”) are not designed to be focused at all, so it was important to code the controls correctly. Otherwise, keyboard users might expect to highlight what looks like a control only to find that pressing TAB has skipped over it entirely!
Aside from HTML form elements such as <input>, only the <a>, (hyperlink) and <button> tags are easily focusable without extra scripting.
Users who are blind or have very low vision and cannot easily interact with a website visually may choose to use a “screen reader“. Screen readers literally read out the contents of the web page using an electronic voice emulator. Most screen reader users are also keyboard users because they cannot see the screen to point the mouse cursor at controls.
Getting an impression of the overall content of a web page can be arduous for screen reader users because, while sighted users can glance and “take in” the overall design almost instantaneously, screen reader users must read it from top to bottom. To make sure that the content in Doc Ready made sense being read in this linear fashion, we had to be careful about the order of the controls and surrounding text. Sometimes special techniques were employed to reorganise the content just for these users.
It was also important to break the content up, so that different parts of each page could be navigated to directly using special screen reader keyboard commands. The simplest way to break up content for screen reader consumption is to use appropriate headings to introduce text.
The most important heading is usually “tagged” with the <h1> HTML element, which is read aloud as “Heading Level One” by the screen reader voice. Users of the JAWS screen reader can use the numbered keys (1 – 6) to skip to headings of the corresponding “level”. If you are testing a site with JAWS, here is a useful list of keyboard commands.
The latest version of HTML — HTML5 — comes with another way to break up content. An extension of HTML5 is the Accessible Rich Internet Applications suite (ARIA), which is a set of provisions to help define the roles, states and other properties of HTML code in an accessible way.
For our purposes, to define important “landmarks” in a web page one can edit the HTML code to include ARIA “landmark roles” for the appropriate areas. In Doc Ready we use a “banner” role to define the header or “banner” of the page. Inside this is a set of links that make up the main navigation for the app. This has a role of “navigation”. The tag that contains all the main content of the page gets a role of… “main”, of course.
Working together, these “landmark” areas act like continents to help describe the map of the page. Not only are they announced when you reach them reading normally but — like headings and links — are also available in a special “elements list” dialog. To access this using the free NVDA screen reader, one simply has to pressINSERT together with F7.
Landmarks are not the only ARIA enhancements that we’ve used in Doc Ready. By using a combination of ARIA attributes (“aria-controls” and “aria-haspopup“) on the section headings in “advice”, we have enabled NVDA to tell users that the heading is a “clickable” control which corresponds to a hidden submenu.
One of our biggest challenges when making Doc Ready as accessible as we could was in handling navigation.
Traditional websites are made of separate pages and, when you click on a link to navigate to a new page, the screen reader starts reading that page on arrival. Doc Ready is a “one page application”, meaning that when you appear to be navigating between “pages” you are really just reconstituting the page that you are already on. This has its advantages: It can speed up traversal through parts of the app and it means data can be easily shared between parts of the app too.
However, it’s not quite so easy for a screen reader to know just when the content on the page has really changed, or where it should start reading from. To solve this, whenever the content on the page changes we use another ARIA feature called “alertdialog” to alert the screen reader to the change and instruct it to start reading the fresh content. So that the keyboard is ready to control the new content, we also manually refocus the box that we put it in.
According to testing, this measure has vastly improved navigation around the app, which would otherwise have been badly broken. However, it is an experimental measure and we welcome any feedback from screen reader users who have tried out Doc Ready.
Throughout Doc Ready’s design and development, we’ve been speaking to young people to test its design, functionality and usability, which includes its accessibility. We feel that we’ve come a long way, but we’re still extremely keen to speak to people to find out what they think and whether Doc Ready is accessible to you.