Feature: Braille only regions for student testing

[aleventhal]

Some testing services use a nonstandard attribute called brailleonlyregion. When JAWS sees this attribute, it will output the region in Braille, but not as text to speech.
Purpose: test someone's ability to read text aloud, without having the screen reader tell them how to do it.

Obviously, not ever screen reader user reads Braille, but apparently Pearson, ETS, Cambium and others have found value in this.

As we are pushing away from supporting any nonstandard attributes (screen readers can currently consume attributes directly via ISimpleDOMNode), we need a standards-based way to provide the same feature.

[cookiecrook]

@mhakkinen Would you or someone else at ETS be able to write the explainer? Doesn't have to be long... Just outline the need, and explain why existing mechanisms (aria-label="masked for test" aria-braillelabel="braille this text") don't provide sufficient utility. Thanks.

[spectranaut]

Minutes from last weeks meeting: https://www.w3.org/2024/10/17-aria-minutes#964a

[aleventhal]

Does anyone know somebody from a testing service who might be able to answer this? @cookiecrook, do you have another way to reach out to @mhakkinen?

[mhakkinen]

Attribute Name: aria-brailleonly (Boolean)

Purpose: The aria-brailleonly attribute addresses the need for content to be presented exclusively in braille for users of screen readers, particularly in educational assessments and other scenarios requiring written text comprehension skills in braille without simultaneous audio output. When this attribute is applied to an element, screen readers should interpret and render the content in braille only, suppressing spoken presentation. This supports visually impaired users, ensuring they can independently engage with content designed specifically for braille reading without audio interference.

Use Cases:

Educational Assessments: In computer-based assessments, students who rely on braille are often evaluated on their ability to read and comprehend braille text without additional auditory input. By marking text with aria-brailleonly, authors can ensure that these assessments maintain their integrity and accurately measure decoding and comprehension skills.

Braille-Specific Training Content: Content intended for braille training, practice, or skill assessment can be delivered exclusively in braille without unintended speech output that could disrupt the learning process.

Why aria-braillelabel and aria-label Are Not Suitable

The existing attributes aria-braillelabel and aria-label do not achieve the specific functionality needed for exclusive braille presentation:

Purpose of aria-braillelabel: The aria-braillelabel attribute is intended to specify alternative text in braille for assistive technologies that support braille output. However, it does not inherently suppress speech output from screen readers.

Therefore, using aria-braillelabel alone does not guarantee that text will be displayed in braille without simultaneous audio.

Limitations of Combining aria-braillelabel and aria-label: While aria-braillelabel can offer a separate braille-specific label and aria-label provides an audible label, there is no standardized mechanism to suppress the audio while retaining the braille display. The combination of these attributes does not ensure that text will be presented exclusively in braille, which is the core requirement for educational assessments and braille-only content scenarios. Placing text in aria-label, such as “Masked Text” or “Check your braille display” produces the audio rendering of the text and could result in confusion for the test taker.

Content redundancy: use of aria-braillelabel for longer texts would result in duplication of the contained text in the attribute value, which can lead to maintenance issues and increased content size.

Other considerations

There are many cases where screen reader users do not read braille, or do not have a refreshable braille device, therefore, a spoken output may be necessary in those cases. This is why screen reader users should have the option of turning braille only regions on or off as a preference setting. This would not be an option in the case of educational assessment contexts, and in those cases the configuration is typically controlled by local administrators. If a braille display is not connected (or detected) by the screen reader, default behavior will have to be determined.

Summary

The aria-brailleonly attribute would provide a standards-based solution to a critical accessibility need, ensuring that content can be rendered in braille exclusively without triggering audio output. This targeted functionality aligns with the educational needs of visually impaired students and facilitates the accurate assessment of braille reading skills, making it a valuable addition to ARIA specification.

[aleventhal]

@mhakkinen is this used for longer texts that have semantics inside, such as tables, headings, lists, emphasis, paragraphs, etc.? If so, I think it makes the argument for creating this stronger. If not, I wonder if the arguments against using aria-label are strong enough. We could make aria-label="" work, at least when there is an aria-braillelabel present. Personally, I always thought aria-label="" should remove the accessible name of an object rather than be ignored markup.

[mhakkinen]

Yes, @aleventhal, longer texts would be an expected use, and may include markup such as lists, emphasis, etc.

[spectranaut]

Discussed in today's ARIA working group meeting: https://www.w3.org/2024/11/14-aria-minutes.html#5604