Three accessibility bugs in a four-option quiz, and the markup that fixed them

In a recent effort to make a nine-question quiz with four options per question accessible, three specific issues were discovered and resolved. The quiz, designed for a ServSafe Manager trainer, aimed to provide a keyboard and screen reader-friendly experience. However, the implementation revealed important accessibility challenges.

Firstly, a details/summary block, used to group questions for initial HTML loading, was causing problems. When VoiceOver, a popular screen reader, encountered the summary, it read the entire block, including a "Show answer" label next to the question text. This made the question unintelligible for users relying on screen readers.

The fix was straightforward: limit the summary to the question text alone, allowing the disclosure triangle to handle the announcement naturally. Screen readers already indicate whether the summary is collapsed or expanded, rendering the additional label unnecessary and redundant.

Secondly, the issue arose around focusability. In some browsers, particularly Safari, details elements were not automatically focusable, and this behavior varied between Chrome and Safari when placed within a list. To address this inconsistency, the solution was to keep the details element as a simple disclosure without any tabindex attributes.

This approach ensured that the answer text, which was already made pure text (and thus focusable), could seamlessly handle keyboard navigation without conflicts or unexpected behaviors.

Thirdly, the method to announce the score without disrupting the user experience was problematic. Initially, a naive solution involved using an assertive live region, which caused the screen reader to interrupt users mid-question each time they selected an option. A better approach was adopted: a polite live region was implemented solely for the score, updating only upon changes rather than on page load.

This prevented the screen reader from interrupting the user, as the score change would be announced only when relevant. Additionally, the live region was kept in the DOM from the start but initially empty, avoiding inconsistencies in how different screen readers handle newly inserted content.

The feedback text following an answer also posed a challenge. It was crucial to ensure that this text did not interrupt the reading of the next question. The solution was to manage focus by moving it to the feedback container after submission. This approach allowed users to decide when to read the feedback, maintaining continuity in their reading experience.

Upon reviewing these issues, it became clear that the key to creating an accessible quiz lies in several fundamental checks. The ability to navigate every question using only the keyboard and the constant awareness of which option is currently selected are paramount. The interruption caused by answer feedback during the question reading process should be avoided.

Finally, ensuring that the score region does not announce upon loading is essential. These three checkpoints address the majority of accessibility pitfalls in a typical four-option quiz scenario.

The principles and fixes identified in this project are not unique to this particular quiz but are applicable to any similar four-option quiz. The accessible markup practices demonstrated here can serve as a template for ensuring that quizzes remain navigable, understandable, and user-friendly across various assistive technologies.