Repository navigation
[EPUB 3.3] [question] Unicode and accessibility #1732
Description
I'm not a Unicode expert, so I'm asking: could the infixations in the Unicode Restrictions section be a problem for screenreaders or Braille displays?
I'm not a Unicode expert, so I'm asking: could the infixations in the Unicode Restrictions section be a problem for screenreaders or Braille displays?
Activity
mattgarrish commentedon Jun 30, 2021
Certainly, but that's generally why you shouldn't use the Private Use Areas for publicly distributed content. Visual readers may not see what the author intends, either, depending on whether the embedded font is supported.
We have an accessibility technique about using unicode for text, so we could probably elaborate on this issue there. I don't think it's something to take up in the core spec since private exchange is perfectly acceptable.
murata2makoto commentedon Jun 30, 2021
@gregoriopellegrino
Now, I do not think that this section is useful.
First, it is not thorough. Different ebook markets may want to introduce different restrictions on Unicode. For example, I would like to disallow Kangxi Radicals and Radical supplement from Japanese EPUB publications.
Second, it is biased. It does not consider T2S or conversion to braille, as Gregorio correctly pointed out.
Third, warnings about the use of Private Use Characters should be in Unicode or W3C Character model. Not in this spec.
iherman commentedon Jul 1, 2021
I believe that the problem with this section is that it unduly picks on the private area. After all, if I create a book that also includes Japanese text (via good-old-Unicode, nothing fancy) I should indeed make it sure, via some CSS statement, that the font I use does include Japanese characters that are properly readable for native speakers. Ie, I agree that the section, as is, should probably be removed.
Whether the more general statement that I have stated above should be part of the spec: I actually doubt. The special case of Braile should, however, be indeed mentioned in the a11y techniques document (maybe @gregoriopellegrino can talk to the editor of that spec 😀)
murata2makoto commentedon Jul 1, 2021
@iherman
I think that "Character Model for the World Wide Web 1.0: Fundamentals" does a good job. I would like to simply reference this W3C Rec.
mattgarrish commentedon Jul 1, 2021
This is a tricky issue as you can make font icons accessible with some work, so it's not always cut-and-dry an accessibility failure to use the private use area. See, for example: https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA24
iherman commentedon Jul 1, 2021
This is in line with:
Does that work?
mattgarrish commentedon Jul 1, 2021
Yes, I'm not sure how it's all that useful. Telling people to embed the font when they use PUA code points is sort of stating the obvious. And in the end it doesn't help when embedded fonts aren't supported.
Ya, we'll have to figure this part out. The techniques aren't supposed to be dealing in general problems like this, either. It's not a new or different issue from the web.
iherman commentedon Jul 9, 2021
The issue was discussed in a meeting on 2021-07-08
List of resolutions:
View the transcript
2. Private use areas in HTML
See github pull request #1751.
See github issue #1732.
Dave Cramer: we had a section in spec that said if you use unicode private use area (PUA) characters, then you should embed a font
… just having that statement in there seemed kind of odd. Its just best practice advice, and don't want to mess with unicode PUA
… PR would remove this section of spec
… mgarrish was waiting for confirmation from WG this was okay
Murata Makoto: is the proposal to entirely remove that section, and nothing else?
Wendy Reid: yes, and adding that to the change log
Brady Duga: there was also a comment on issue of moving it to discouraged constructs
Murata Makoto: in spec we refer to CHARMOD matching, but not CHARMOD fundamentals. I think we should refer to Fundamentals, too, fundamentals has a section dealing with PUA codepoints
… we should try to rely on these instead of inventing our own. Don't want to do anything that goes against what is already in Fundamentals
Wendy Reid: Ivan made the point that we rely on HTML5, which already refers to CHARMOD documents
Dave Cramer: to my mind this is an HTML question, and HTML refers to CHARMOD, so I don't see need for us to explicitly refer as well
Murata Makoto: does SVG refer to CHARMOD too?
Brady Duga: whether or not SVG does seems like a minor thing. It already encompases so much more, e.g. allowing authors to draw whatever characters they want
Shinya Takami (高見真也): MURATA's opinion is not an objection to this proposal
Murata Makoto: yes, just suggesting a minor change
Dave Cramer: propose we accept this PR. If we have big problems with SVGs and PUA, then we can revisit
iherman commentedon Jul 9, 2021
@gregoriopellegrino there is a WG resolution to merge #1751 (which should happen later today). If you think that answers your issue, can you close this? Thx.
mattgarrish commentedon Jul 22, 2021
Closing this issue as there hasn't been any further feedback on it.