Crosswords for visually challenged

Accessibility is a major concern for publishers. They want to make sure as many of their products are accessible to the visually challenged as possible. Hence, we had to take up the challenge of making crosswords accessible to the visually challenged.

Crosswords have two main components—the grid and the clues solving involves going back and forth between these. Another unique property of crossword solving experience is that the grid may contain letter hints because of the filled intersecting words in the grid. Additionally, there are other features available on the screen such as reveal, check, timer, settings, etc. For someone with the ability to see navigating through these components is not difficult. Creating an experience for visually impaired users with as much possibility as possible while keeping the interactions easy to use was our goal.

Process

ChromeVox, a Chrome extension developed by Google, that makes browsing accessible, and other similar platforms use an HTML attribute called ‘aria-label’ which is read out when that element is selected i.e. ‘is in focus’. Elements that need to be ignored can have the attribute ‘aria-hidden: false’. This works well for a simple HTML page where the only interactions one can have on the page are navigating over elements and clicking on them. However, since solving crosswords requires a lot of back and forth between various elements, just setting ‘aria-label’ attribute would not solve the problem.

I was a little overwhelmed when I started working on this due to the amount of interaction required from the user to solve a crossword and the number of options. I did not have prior experience with building accessibility-friendly systems. I did some research by reading about WebAIM, studying various accessibility-friendly interfaces, and using the inbuilt screen reader options on phones and laptops. I also tried integrating ChromeVox with our platform by dynamically changing the ‘aria-label’ depending on the interaction so ChromeVox could read it out but it wasn’t as flexible as we wanted. So I decided to build the feature from scratch using WebSpeech API which gave us better control over the user experience.

Another challenge was to avoid the instinct of making every option and interaction accessible. I grouped the options and interactions into 3 groups—essential, good to have, not required in the first version and so we could approach the problem in stages. 

Essential: reading out clues and filled answers, entering answers, navigating between clues. 

Good to have: reveal and check options, advanced clue navigation, timer, start and end message.

Not required in the first version: linked clues, user settings such as skipping over filled letters, social play, navigation to and from the parent page, etc. 

The message to be read out had to be generated dynamically after each user action. For example, when a new clue or box in the grid is selected, the selected clue, word lengths followed by the current state of the word in the grid i.e. number of blank cells and filled letters (if any) and the current position of the cursor in the word had to be uttered. Upon entering letters, the entered character had to be uttered and when one of the options such as reveal word was performed, the action and the response had to be uttered. For example, “What Romeo and Juliet planned to do, 2 blanks, O, P, one blank, first box selected”.

Result

The final feature supported the following functions—using Tab & Shift+Tab to navigate through the clues, using '.' to change the direction and shortcuts below (currently, only Mac is supported).

Control + R —> Reveal word

Control + B —> Reveal box

Control + G —> Reveal grid

Control + C —> Check word

Control + X —> Check box

Control + T —> Know time elapsed

This feature has been released on all of Amuse Labs’ leading customer sites.

You can try it out below. Select a clue to get started (make sure your volume is up).