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

[cookiecrook]

@mhakkinen Can testing services use unicode braille instead?

• The following is the answer to the great question of life, the universe, and everything.
• ⠼⠙⠃
• What is it?

The speech of the dot patterns: "dots 3 4 5 6, dots 1 4 5, dots 1 2" does not give away the answer.

[aleventhal]

James would you do something like add aria-hidden="true" on the original region, so that it's still visible for the sighted students, and then an offscreen region with the Braille unicode for the screen reader users? Even if that works, I guess the testing services would need a Braille translation engine to generate the test then. And some students may need grade 1 vs others using grade 2, or even computer Braille. This is something the screen reader usually takes care of.

[mhakkinen]

@mhakkinen Can testing services use unicode braille instead?

• The following is the answer to the great question of life, the universe, and everything.
• ⠼⠙⠃
• What is it?

The speech of the dot patterns: "dots 3 4 5 6, dots 1 4 5, dots 1 2" does not give away the answer.

@cookiecrook that will still be ongoing speech, distracting when the student is reading the braille display, and not an equitable experience (unless you play the same audio for the sighted student reading the on screen text). No, this won't work.

[mhakkinen]

FYI I discussed the issue of brailleonly with the QTI working group today, and I will draft a proposal for the group to review for our meeting in two weeks. We will share here once we have consensus.

[NSoiffer]

@cookiecrook wrote:

The speech of the dot patterns: "dots 3 4 5 6, dots 1 4 5, dots 1 2" does not give away the answer.

I disagree. Even I can translate that into the number (assuming that it is UEB and not some other braille code). When I talk to a braille expert and they explain some braille issue to me, they often say "that should use dots ...". I suspect that same speech happens in a classroom ('to change the meaning of the letters a-j to be a digit, add dots 3 4 5 6 in front').

[cookiecrook]

not an equitable experience (unless you play the same audio for the sighted student reading the on screen text).

The sighted student would see the rendered characters... As you do here: ⠼⠙⠃How is that inequitable?

Is there any other use case for this outside the context of a braille proficiency test?

Maybe there is another set of "test-only" proposal this could be added to... For example, language tests that allow (only with user opt-in permission) to disable the auto-language translation features common in browsers today. Does QTI (or any W3C group) have an ongoing feature list for test-only web features?

[cookiecrook]

@NSoiffer wrote:

I disagree [that it doesn't give away the answer]. Even I can translate that into the number (assuming that it is UEB and not some other braille code).

It's literally just the same dots that are rendered on the display though, which can be perceived tactilely or visually. You still have to known braille to understand those dot patterns. This doesn't give any additional information unless you've set up an even more specific test scenario: the speech gives more information to a hearing blind user than a deaf blind user with limited tactile perception.

When I talk to a braille expert and they explain some braille issue to me, they often say "that should use dots ...". I suspect that same speech happens in a classroom ('to change the meaning of the letters a-j to be a digit, add dots 3 4 5 6 in front').

Yes, I can do that too for uncontracted English braille and some contractions. But I can do it because I know that subset of braille.