Inaccessible Web accessibility advice from the Ontario governement

Photo of Ontario Accessibility Resources booklet
Ontario Accessibility Resources booklet

The Ontario provincial government published a booklet called “Ontario Accessibility Resources” aimed at helping businesses implement inclusive work practices and accessible product design. The booklet recommends a handbook by RGD, the Association of Registered Graphic Designers: “Access-Ability: A practical handbook on accessible web design“. Actually there is a typo in the booklet, it uses a “.ca” extension for the RGD website and not “.com”, I’ve provided the corrected link.

I want to talk about RGD’s website. It contains lots of very useful content, but there are significant accessibility problems with the site delivering the advice. I will focus on the the page with the link to download a PDF version of the advice document. A later blog post will consider the document itself.

RGD’s website

Figure 1 below shows the jumping off point for downloading the booklet in PDF format.

Figure 1: Screenshot of the RGD jumping off page for the booklet
Figure 1: Screenshot of the RGD jumping off page for the booklet

I’m concerned about figure 1, because it’s not well designed for accessibility. If you are going to produce a booklet on web accessibility, then you need to make sure that your own website is accessible as an exemplar to others. In particular there are problems for users with low vision. The magnifying glass/search icon is at the top right of the (responsive) Web page. Typically with websites the search button is to the right of a text entry box, but not here. On this page, the search text box opens on a new line and the input is centred, see figure 2 below.

Figure 2: image of search box opened and displaying on a new line, horizontally centred
Figure 2: search box opened and displaying on a new line, horizontally centred

There are multiple accessibility problems with figure 2.

  1. The UX behaviour is non-standard. There is nothing necessarily wrong with this per se, but unusual interaction modalities and surprises with screen-readers do not add to accessibility. It’s easy to see what is happening on-screen if you can see the whole page, much harder with a screen-reader or a screen magnifier. Also unusual is that the icon opens and closes the search box, it does not cause a search to start; again an unusual Web input modality; this is amplified when using a screen-reader which will say, “Search the site button”.
  2. Navigation order is also off for the search button; tab order goes from the RGD logo link, to the search button and then back to “Print”. For a blind person using a screen-reader this is not a problem, but for sighted and partly sighted users,  this is not ideal. It is not only blind users who use keyboard short-cuts and screen-readers, people with low (but some) vision, and users with cognitive impairments also use them and they benefit from a natural left-to-right, top-to-bottom tab order. On some web pages this is not possible, but for a main menu I would expect that order to be followed.
  3. The open/close action of the search button does not properly announce with a screen-reader. When the search line is closed, Jaws 17 reports “Search the site button”. On select, the focus correctly changes to the input box and Jaws eports the search region. Tabbing back to the search button and then selecting it, Jaws 17 reports “Space”. This is a problem we recently had on the celalibrary.ca website when we added folding media player. It requires very careful scripting to ensure screen-readers correctly report collapsing regions, and RGD need to revisit their search menu.
  4. Still with the search button, there are colour contrast issues. Actually, the same issue appears across the site. The default button colours of black on gray (RGB #D9D9D9) pass WCAG 2.0 AAA requirements. The problem is that you really want the box with the icon in to stand out on a white page, and there the contrast ratio is only 1.4:1. So the image in the button is clear, but the button on the page is not.
  5. Colour contrast for the roll-over of the search button is also an issue. The rollover changes the gray background to yellow (RGB #FCE853) which improves the colour contrast from 7.1:1 to 9.0:1, so the intensity of the background increases slightly but that’s all. A safer option would be a colour inversion. As with the gray background colour, yellow on white provides a poor contrast, in fact even worse than the gray on white with a contrast of only 1.2:1.
  6. If the user requires a screen magnifier, then the focus of the text box is a significant distance from the cursor. With high magnifications, it may not be even visible. Magnifier software does try to help, potentially adding a highlight around the text box, and a second highlight around the input focus, but this is still not ideal. I understand the the idea of having a full line for input text – this helps with cognition issues, but separating the icon from the text box by such a distance is not great UX design.
  7. There is a major design problem with navigation to the footer menu. To reach the footer menu by tabbing in a screen-reader, the entire content must be first traversed. On most we pages this does not present too many problems as there are not normally too many links to tab through. On the “print” page shown in figure 1, there are many. These are caused by the content of the Twitter pane which as on , has 145 links to tab though; almost all of these are to older tweets. At the end of the 145 links is the about us and contact us pages. So a blind user must navigate the entire 145 links to reach the contact page.
  8. The accessibility problem with navigating to the footer menu is one frequently encountered on websites. I would recommend that no important menu items exist in the footer for this reason, particularly contact details and feedback forms. Given that one of the things disabled users may need to do is report broken web pages, it would seen sensible to ensure this feature is easily accessible from a screen-reader, for example as a hidden menu link after skip to content.
  9. There is a problem with the quality of the text used in links. Figure 1 shows two links in the main body of the page, one to “Download the file here” and one to “click” here. These are poor quality for users of screen-readers. Screen-readers such as Jaws pull out all the links on a page to allow the user to navigate them as a list; a list of links called “click here”, stripped of their context are meaningless, and it is why the text used in links should be meaningful with the link stripped of context.
  10. Fonts; there are text elements with a relatively small font size of 12 pixels, including navigational elements. Whilst the minimum acceptable font size is usually taken to be around 10-11 pixels, anything below 14 is a little low, at least in my experience at CNIB. We have a large corpus of visually impaired users and we get hit over the head if our font size drops below 14 pixels by default. So whilst the standard says okay at 12 pixels, my user base says otherwise. On balance, I would recommend navigational elements at least, stay at 14 pixels or higher.
  11. A perennial problem on text input boxes is the default text colour contrast, and the RGD site is no exception. When the search box is opened, default text of “search term” is presented in a grayed out form, with a colour contrast ratio of 2.1:1, failing even WCAG 2.0 AA. If the text is needed by sighted users, then it also needs to visible to users with low vision.
  12. The site has a problem with highlighting input boxes, image links, and input cursors. Whilst there are great magnifier tools that can be configured to help with input box and cursor highlighting, it is wrong to depend upon them. It should be clear to a person with low vision when they are hovering over an input field, and when the input focus is on a the field. Similarly, image links usually need more than a change to the pointer cursor to indicate rollover as the image can be too noisy to easily notice. With image links, there also needs to be some visual cue when the link has focus if the user is tabbing through links.
  13. The site has chosen not to provide alternate colour themes which is unfortunate. They have instead left that to assistive technology. Given that people do not always view content on their own computers, it is best not to make too many assumptions about the available assistive technology. Additionally, the tools that invert colours do not necessarily make for accessible content. Where icons have been used in navigation for example, they do not get recoloured correctly. I wouls strongly recommend sites provide at least a yellow on black theme as an alternative if they use any navigation icons or info-graphics.
  14. One further problem with the search button – it does not render reliably when a screen-reader is in use and the user is tabbing, see figure 3 below. The search button seems to get rendered separately and away from the magnifying glass icon. It appears after the user tabs forward away from the search box and then back to the search button. That this was not picked up make me wonder about the level of testing undertaken using a screen-reader; on a site promoting inclusive design that seems odd.
Figure 3: Rendering problem with search button appearing separately to the magnifying glass icon
Figure 3: Rendering problem with search button appearing separately to the magnifying glass icon

Reflection on the findings

It is unfortunate to have to report quite so many problems with a web page offering web accessibility advice. Not all problems are equally serious but taken together, I would recommend RGD re-visit their site design. It is important that web documents teaching web accessibility practice what they teach.

Leave a Reply

Your email address will not be published. Required fields are marked *