OpenAccess

aria-braille*: accessibility support tests

Callum McMenamin — 11 April 2025

aria-braille* attributes are in the WAI-ARIA 1.3 draft spec. This post shows my assistive technology testing results.

Introduction

The Accessible Rich Internet Applications (WAI-ARIA) 1.3 Editor’s Draft defines two new Braille-related attributes:

• aria-braillelabel
• aria-brailleroledescription.

I noticed that WebKit recently introduced support for these attributes, announced in WebKit Features in Safari 18.0 — webkit.org.

I also use the aria-braillelabel attribute in this website’s logo, so I had better test that it works. To read the article about the OpenAccess logo, read: What a logo looks like, sounds like, feels like.

🚨 WARNING: aria-braillelabel is currently in the WAI-ARIA 1.3 draft specification — it’s not finalised. The attribute could change at any time. Don’t try this at home — we’re trained professionals! Well… actually, you can try this at home if you’re aware of the risks, and know what you’re doing. I don’t think using this attribute will cause any harms if you carefully assess how all supported assistive technologies behave while using the attribute.

Test page

aria-braille* test page

Test case summary

The tests will cover the behaviour of aria-braillelabel and aria-brailleroledescription on <button> and <img> elements, including how attributes like alt and aria-label influence the results.

Each test on the aria-braille* test page has an a test case name that matches those used in this article.

Test case naming convention

Test case names start with “B” for “button”, or “I” for “image”.

• B1 is testing how aria-braillelabel works on a <button>, and whether it overrides the accessible name provided by the text content of the <button>.
• B2 is testing how aria-braillelabel overrides the aria-label specified on a <button>.
• B3 is testing how aria-brailleroledescription works on a <button>.
• I1 is testing how aria-braillelabel works on an <img> and whether it overrides alt attributes.
• I2 is testing how aria-braillelabel works on an <img> and whether it overrides the accessible name specified through an aria-label attribute.

Accessibility support baseline

Unfortunately, I am unable to test Braille features for VoiceOver on iOS, Narrator on Windows, and TalkBack on Android because these screen readers appear to lack a “braille viewer”. I don’t have a Braille display yet — but I am in the process of getting one. If someone out there would like to complete the testing for iOS, Narrator and TalkBack for me, please reach out via the contact page.

macOS

Enabling Braille Panel

Enabling macOS VoiceOver Braille Panel

To enable the macOS Braille Panel, go to:

1. VoiceOver Utility
2. Visuals
3. Panels and Menus
4. Show Braille Panel > On

macOS provides a way to visually preview Braille output on screen, even without a physical Braille display. The VoiceOver Braille output provides contractions to save space on the Braille display, where "heading" becomes "hd", and "level" becomes "lvl".

Test: macOS + Safari + VoiceOver

Test: macOS + Brave + VoiceOver

Test: macOS + Firefox + VoiceOver

Windows 11

Enabling Braille viewers

NVDA Braille Viewer

To enable the NVDA Braille viewer:

1. Open the NVDA context menu from the taskbar
2. Tools
3. Braille viewer

NVDA has a way of viewing Braille output on your screen visually, without a Braille display.

JAWS Braille Viewer

To enable the JAWS Braille Viewer, go to:

1. JAWS Professional
2. Utilities
3. Braille and Text Viewer
4. Show Braille Viewer

JAWS has a way of viewing Braille output on your screen visually.

Test: Windows + Firefox + NVDA

Test: Windows + Edge + NVDA

Test: Windows + Firefox + JAWS

Test: Windows + Edge + JAWS

Conclusion

Support for aria-braille* attributes is a bit of a mixed bag.

I have learnt:

• Firefox has no support for aria-braille* attributes on macOS
• aria-braille* attributes work really well across macOS in Safari and Chromium
• aria-braille* attributes work well using JAWS on Windows, but not NVDA.

If only I could complete this testing using a refreshable Braille display. Having the data for TalkBack, Narrator, and VoiceOver on iOS would be nice.

I’m comfortable with my usage of aria-braillelabel in this website’s main logo — I think it probably provides an enhanced experience for those OS/browser/AT combos that support it, while causing no issue for those that don’t. I think it’s a great idea for an attribute — and I hope developers use it correctly 😅