Accessibility self review

[frivoal]

This review is based on the 23 May 2024 WD, answering question from APA's FAST Checkliks

Prelude:

This specification extends an existing feature rather than introduce a new one. Maybe of the accessibility characteristics of this technology pre-exist in the underlying feature. This extension improves upon them.

Ruby, at its core, associates text with one (or more) annotations about the text, with the intent of displaying the annotation along side the annotated text, in a visually distinct way. Although this can be used for a number of reasons, the primary motivation is primarily an accessibility feature targeting people, who for a variety of reasons, have difficulty reading the base text. By far, the dominant use case is for ideograph based east-asian languges, where learning the writing system requires memorization of thousands of different letters. Children, non-native speakers, people with learning disabilities, or people from under-privileged backgrounds and with a limited education, frequently struggle to read unassisted. Ruby enables phonetic annotations to be attached to the potentially challenging text, thereby making otherwise unreadable content accessible to more readers.

These annotations are typically displayed between lines of text immediately above or below the words they annotate, though alternative presentations can be desired and are enabled by CSS in general, and https://www.w3.org/TR/css-ruby-1/ in particular.

All this is true prior to this extension specification. However, the markup patterns enabled by the HTML standard, while concise and effective in simple cases, are insufficient to handle all use cases well. In particular, while it does enable authors to indicate annotation is associated with which word, it does not give them sufficient tools for authors to also indicate which part of the annotation is associated with which character in the base word, unless they are willing to sacrifice the natural document order, and interleave parts of annotations between parts of words.

The negative consequence of not having a complete mapping of annotation parts with base text parts while respecting the natural document order is that authors need to change their markup depending on the specifics of the visual rendering they intend, as not all presentations can be supported from the same semantic markup. Further, some markup patterns, necessary for some desirable presentational characteristics, break other features, such as search ability or copy and paste, due to unnatural interleaved markup patterns they require.

A key goal of this specification is to remedy these downsides, by offering markup patterns that convey the complete relations between the base text and its parts with the annotation and its parts, while respecting the natural order of the text. From there, authors and user or user agents can offer alternative presentations without modifying the markup, and no longer have to make compromises such as choosing between proper alignment and proper line breaking, while the natural order of the text in the markup avoids the search / copy-paste / or speech synthesis ordering problems that could occur with otherwise.

Occasionally, having multiple levels of annotation over the same base text can be desirable. The current HTML spec purports to address this, but the way it specifies this is not implemented in user agents, and suffers from similar inflexibilities. The markup model defined by extension specification addresses this issue as well.

A known pre-existing challenge with ruby, which this revision of the specification does not attempt to address, relates to speech
synthesis: when faced with annotated text, should screen-readers or other text-to-speech systems read the base text, the annotation, or both? Depending on the use case, the appropriate answer may vary, and picking the wrong answer can be confusing to the reader. There currently is no good way for authors to indicate their intent, or for user-agents to infer it reliably. This extension specification does not address the problem, but does not make it worse either. The i18n Working Group is pursuing an exploration of this problem space, documented in https://w3c.github.io/ruby-t2s-req/. We hope that to tackle this in a later project. For the moment, with this extension specification, the focus is on getting the basic markup structure right.

Answers to the questions:

• If technology allows visual rendering of content
  This technology is HTML markup for text, it does enable visual rendering. The same CSS/HTML/… techniques that apply to any and all HTML textual markup apply here to.
  • There is a defined way for a non-visual rendering to be created. Since this spec un-obsoletes <rb> and <rtc>, we should revert the Removal of obsolete elements RB and RTC html-aam#253 Pull request, which removed them from HTML accessibility mappings when they were obsoleted.
  • Content can be resized. (usual HTML/CSS/… answer)
  • Luminosity and hue contrast can adapt to user requirements. (usual HTML/CSS/… answer)
  • Text presentation attributes can be changed. (usual HTML/CSS/… answer)
  • Visual presentation of pointers and cursors can be adjusted. (usual HTML/CSS/… answer)
  • Changing content presentation does not render it unreadable. As discussed above, without this extension specification, not all presentations can be achieved from a single markup pattern, and trying to change can result in undesirable results. This specification remedies this problem
  • Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it. (usual HTML/CSS/… answer)
  • It is possible to make navigation order correspond to the visual presentation. As discussed above, without this extension specification, it is sometimes necessary to put things out of order in the markup in order to get the correct visual rendering. This specification remedies this problem
• If technology provides author control over color
  This technology is HTML markup for text. It does not introduce new abilities to control color, but usual CSS techniques apply.
  • There is a mechanism for users to override colors of text and user interface components. (usual CSS/… answer)
  • There is a feature for authors to define semantically available "color classes" that users can easily map to custom colors, and give preference to this vs. coloring objects individually. (usual CSS/… answer)
  • There is a feature for users to choose color schemata that work for them. (usual CSS/… answer)
  • The foreground and background color of an object can be reported to the user via AT. (usual CSS/… answer)
  • There are ways to set foreground and background colors separately for all objects. (usual CSS/… answer)
  • Compositing rules for foreground and background colors are well defined. (usual CSS/… answer)
• If technology provides features to accept user input
  It does not.
• If technology provides user interaction features
  It does not directly offer any new interaction capabilities.
• If technology defines document semantics
  It is used in an HTML document. Many answers to the questions asked are provided by HTML itself, not by this extention
  • Authors can title Web pages. (usual HTML answer)
  • Authors can title sections of content. (usual HTML answer)
  • Authors can clearly indicate the target of a hyperlink and function of a control. (usual HTML answer)
  • Authors can indicate content language, for the page as a whole and for blocks of content. (usual HTML answer)
  • Authors can support understanding of abbreviations / acronyms / initialisms, idioms, jargon, etc. @@@@
  • Authors can support correct machine pronunciation of ambiguously spelled terms (e.g., in the phrase "I am content with this content" there are different correct pronunciations of the lexeme "content"). This is a pre-existing problem, which this specification neither introduces nor resolves. We intend to look into ways to address it in follow up projects. See discussion above
  • Authors can identify regions of content, particularly the "main" region. (usual HTML answer)
  • Declarative mechanisms (that have accessibility semantics pre-defined in the spec) are used to implement technology features whenever possible. (usual HTML answer)
  • There are unambiguous ways to express relationships between units of content, such as object nesting, ID referencing, etc. As discussed above, this was not entirely true of ruby markup prior to this extension specification, but this specification does remedy this problem
  • Prefer structural semantics to presentational semantics. As discussed above, this was not true of ruby markup prior to this extension specification, but this specification does remedy this problem
  • When providing presentational semantics, they can be easily mapped to structural semantics, e.g., to support restyling or meaningful exposure to accessibility APIs. (usual HTML answer)
  • Support a comprehensive set of authoring use cases to minimize the need for alternative content. (e.g., don't make authors resort to text in images to get the style they want). (usual HTML answer)
  • Semantics allow precise and replicable location information in the document to be determined. (usual HTML answer)
  • Semantics exist to convey meaning that is commonly conveyed via presentation. As discussed above, this was not entirely true of ruby markup prior to this extension specification, but this specification does remedy this problem
• If technology provides time-based visual media
  It does not.
• If technology provides audio
  This technology does not provide audio in and of its own. See the discussion above for remarks about interaction with screen-readers.
• If technology allows time limits
  It does not.
• If technology allows text content
  • Authors can define non-text alternatives for text content. _Ruby enables annotation of content. typically text annotates text, but text can annotate images, images can annotate text, images can annotate images… there's no restriction.
  • Authors can define non-text alternatives for non-text content. Same as above
• If technology creates objects that don't have an inherent text representation
  Not really applicable. It creates relatationships between other bits of HTML markup, not really new objects.
• If technology provides content fallback mechanisms, whether text or other formats
  The questions are not really applicable, because Ruby provides alternate content / annotations over content, which are not inherently "fallback" content, as they are not meant to be displayed instead of the main content when it fails, but along side it. Nevertheless, CSS can be used to show or hide some of the alternatives, and the markup patterns enable knowing which content is primary and which is annotations for it. This is true of pre-existing ruby markup, and remains true with this extension.
• If technology provides visual graphics
  it does not
• If technology provides internationalization support
  • Accessibility features can be internationalized to the same degree as other features
• If technology defines accessible alternative features
  • Accessible alternatives themselves meet the same bar of accessibility.
• If technology provides content directly for end-users
  • Content can be encoded in a manner that allows machine transformation into accessible output
• If technology defines an API
  It does not. (HTML does, but and this fits within that, but it does not define a new API)
• If technology defines a transmission protocol
  It does not.