Bug 225066 - AX: Determine correct behavior for Unicode Private Use Area characters
Summary: AX: Determine correct behavior for Unicode Private Use Area characters
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-04-26 12:06 PDT by James Craig
Modified: 2021-04-26 14:13 PDT (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description James Craig 2021-04-26 12:06:56 PDT 
The accessibility behavior for Unicode's private use area https://www.compart.com/en/unicode/block/U+E000 is currently ambiguous. Some web icon font packages are using (possibly misusing) this area for custom icon fonts... 

For example, FontAwesome uses U+F700 as an "otter" icon... https://fontawesome.com/icons?d=gallery&p=2&q=otter&c=animals

FWIW, despite the FontAwesome site claiming "Accessibility-Minded, Font Awesome loves screen readers!" it does not appear that they've attempted to make it accessible, so I would not expect VoiceOver to speak "Otter" 

However, VoiceOver speaks literally "link " , but pronounces it as "link Up Arrow" and renders to the VO caption panel as "link ↑").

This also isn't right, so its worth investigating the behavior. It's not immediately apparent to me where the replacement "↑" character or its spoken "Up Arrow" string is coming from.

https://www.compart.com/en/unicode/U+F700

I get the same behavior with both Alex and Samantha voices, so it doesn't appear to be coming from the speech engine either.
Comment 1 Radar WebKit Bug Importer 2021-04-26 12:07:12 PDT 
<rdar://problem/77169314>
Comment 2 James Craig 2021-04-26 12:23:33 PDT 
Related to bug 159022