[Webkit-unassigned] [Bug 277990] New: AX: Improve WebKit accessibility output of ambiguous Ruby

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=277990

            Bug ID: 277990
           Summary: AX: Improve WebKit accessibility output of ambiguous
                    Ruby
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Keywords: InRadar
          Severity: Normal
          Priority: P2
         Component: Accessibility
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jcraig at apple.com
                CC: andresg_22 at apple.com,
                    webkit-bug-importer at group.apple.com

Despite some ambiguities in Ruby of which text to speak:
https://github.com/w3c/htmlwg/issues/27

WebKit should have default behavior that will result in the correct output (speech, etc) for the majority of Ruby uses.

Fantasai wrote up some rough behavior expectations:

Rough cut at what good "default" behavior would be:
- If the base text of a <ruby> element (i.e. excluding <rt> element content) is a sequence of kanji, compare that to a dictionary lookup of that word for the kana.
- If the small-kana-mapped phonetics match, drop the <rt> text from AT readout.
- If they don't match, but are still all kana, drop the base text from AT readout.
- Otherwise, read both.
- For zh-TW, the rule is probably the same, but with bopomofo instead of kana.
- For zh-CH, the rule is the same, but with Latin; and ignore rule #3.
- For Japanese it's important to sequence all the base text together before doing a dictionary lookup, not just pair by pair.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240813/3f387be6/attachment-0001.htm>