Accessibility

In 2019, Accessibility Lab carried out a Web Content Accessibility Guidelines (WCAG) 2.1 Audit of Hypha. This document serves as a summary of the high-impact issues that were highlighted in the report.

Information, structure and relationships¶

Labels must be programmatically associated with their control - every form input and control needs a label, or an accessible name. The best way to implement this is to use the html <label> element, because that’s what it was designed to do. Use <fieldset> to semantically group the form fields and use a <legend> to provide a semantic group label.

Sensory characteristics¶

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. Using a graphical symbol can make content difficult to comprehend (i.e. search icon without a visible descriptive text). An image with a text alternative can help in this case.

Use of color¶

Color was used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. As an solution, a:hover and a:focus styles were changed to make the hover state more visible and not just depend on color.

Visual presentation¶

It was noted in the report that the colors of user interface components needed to have more contrast with each other. The contrast of text to background (both for the contrast minimum and contrast enhanced) was increased as a result.

Keyboard accessiblity¶

The report found that almost all functionality of the content is operable through a keyboard interface, but in order to comply with this requirement 100%, ContentEditable (text editor) needs to be made accessible with a keyboard.

Name, role, value¶

For all user interface components (including but not limited to: form elements, links, and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies. The only issue that was found was with ContentEditable (text editor) — issues found with getting to the toolbar with just a keyboard and issues with lacking visual focus.

A mechanism is available to bypass blocks of content that are repeated on multiple web pages - a keyboard functional “skip” link should be provided to allow keyboard users to navigate directly to the main content.

Link purpose (in context)¶

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

Headings and labels¶

Headings should describe topic or purpose and should not skip hierarchical levels, use headings in proper hierarchical order, (<h1> to <h6>). The content under a heading relates logically to the heading above it. <h2> content relates logically to <h1> above it. In this way, the heading structure of a document can be used as a method to organize the documents’ contents hierarchally much like an outline.

Focus visible¶

This requirement specifies that any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. It was highlighted in the report that all links on a:hover and a:focus need a style that does not only depend on color. This was implemented as a result.

Label in name¶

For UI components with labels that include images or images of text, the name contains the text that is presented visually.

Target size¶

The size of the target for pointer inputs is at least 44x44 CSS pixels except in special cases. It was noted that some icons on mobile need to be bigger and more separated to allow for easy use with a finger without risking selecting an adjacent link or button.

Labels and instructions¶

Labels or instructions need to be provided to help users understand how to complete the form and use individual form controls. It was recommended to display which input fields are required using aria-required=true.

Input assistance (error identification)¶

If an input error is automatically detected, the error is identified and described to the user in text. It was recommended to use aria-describedby to programmatically associate the error message with the input field. This was implemented as well as moving the focus to the first field with an error.

Error suggestion¶

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Error prevention¶

For web pages that require the user to submit information, at least one of the following is true:

Reversible- submissions are reversible
Checked- data entered by the user is checked for input errors and the user is provided an opportunity to correct them
Confirmed- a mechanism is available for reviewing, confirming, and correcting information before finalizing the submission

Parsing¶

For content written in markup languages, the content needs to be parsed into a data structure.