- From: John Foliot <john.foliot@deque.com>
- Date: Fri, 30 Aug 2019 10:25:10 -0500
- To: Janina Sajka <janina@rednote.net>
- Cc: Accessible Platform Architectures Administration <public-apa-admin@w3.org>, Ada Rose Cannon <ada@ada.is>
- Message-ID: <CAKdCpxzF-NydsPQf3XByA57ZoeLDxW5ZzZuojCtQ5PFatuZYYg@mail.gmail.com>
+1 JF On Fri, Aug 30, 2019 at 9:35 AM Janina Sajka <janina@rednote.net> wrote: > Colleagues: > > This is a Call for Consensus (CfC) to the Accessible Platform > Architectures (APA) Working Group concerning our draft response to the > Immersive Web Working Group on their requested accessibility review[1] > of their XR Device API specification: > > https://www.w3.org/TR/2019/WD-webxr-20190521/ > > ***Draft Comment*** > > Thank you for requesting our review of your XR Device API from an > accessibility perspective. Our response today is based on a close > reading of this specification by two APA members[2] and a subsequent > discussion of their findings during a regularly scheduled APA > teleconference.[3] > > We have found no explicit accessibility problems in this specification, > so we have no objection to it moving forward toward W3C recommendation > status as currently specified. > > However, our review has raised a series of questions and concerns, and > we will now look for opportunities to engage with you to establish a > fuller understanding of accessibility opportunities and challenges in XR > technology, as well as greater support for accessibility use cases in > future revisions of your specifications. A significant concern for us is > the question of how semantically rich representations of XR are to be > provided? Semantic constructs are critical to supporting accessibility. > > APA wishes to acknowledge our great interest in the emerging XR > technology. Toward that end an initial request for a joint meeting > during TPAC is forthcoming. We are also happy to see the announcement of > a W3C Workshop on "Inclusive Design for Immersive Web."[4] > > We look forward to working with you more directly as XR matures. > > *** ACTION TO TAKE*** > > This CfC is now open for objection, comment, as well as statements of > support via email. Silence will be interpreted as support, though > messages of support are certainly welcome. > > If you object to this proposed action, or have comments concerning this > proposal, please respond by replying on list to this message no > later than 23:59 (Midnight) Boston Time, Friday 6 September. > > Best, > > Janina > > NOTE: This Call for Consensus is being conducted in accordance with the > APA Decision Policy published at: > > http://www.w3.org/WAI/APA/decision-policy > > [1] http://lists.w3.org/Archives/Public/public-apa/2019Jul/0012.html > [2] http://lists.w3.org/Archives/Public/public-apa/2019Jul/0051.html > [3] https://www.w3.org/2019/08/28-apa-minutes.html#item04 > [4] http://lists.w3.org/Archives/Public/public-apa/2019Aug/0067.html > > > > ------------------------------------------------------------------------------ > > Janina Sajka > > Linux Foundation Fellow > Executive Chair, Accessibility Workgroup: http://a11y.org > > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) > Chair, Accessible Platform Architectures http://www.w3.org/wai/apa > > Here is my proposed feedback to the Timed Text Working Group: > > > > <draft-feedback> > > > > 1. While we appreciate that TTML Profiles for Internet Media Subtitles > and Captions 1.1 <https://www.w3.org/TR/ttml-imsc1.1/> is depending on Timed > Text Markup Language 2 (TTML2) <https://www.w3.org/TR/ttml2/>, it > should still include an introduction that guides the reader to a better > understanding of its content. Such an introduction could respond to the > following questions: > 1. Why are profiles needed for text-only and image-only > captions/subtitles? > 2. What are typical use cases for a image-only captions/subtitles? > 3. What is the purpose of a presentation processor, and a > transformation processor? > > > > 1. There is a general issue with the way that an author specifies > layout characteristics of captions and subtitles, such as font size, font > family, line height, background and positioning. The spec describes the > approach of the author specifying a “fixed layout” for captions and > subtitles that the user cannot change. However, it must be possible for > the user to overwrite the author’s choice of font size, or background > color, for example. This is necessary for accessibility reasons, in the > same way that browsers allow the user to change font size and background > color. How can we find a good solution for these conflicting interests > between author and user? We would like to get into a discussion with you > on this issue. > > > > 1. Section 2 Documentation Conventions (applies also to Timed Text > Markup Language 2 (TTML2) <https://www.w3.org/TR/ttml2/> section 2.3). > For accessibility of the spec, information such as whether an element is > deprecated or obsoleted should not be indicated by color (or background > color) alone (cf. WCAG 2.0 SC 1.4.1 > <https://www.w3.org/WAI/WCAG20/quickref/#visual-audio-contrast-without-color>). > > > > > 1. Section 5.1 General. The method of associating a text profile > document instance with an image profile document instance should be > specified for interoperability reasons, and not be left open to the > specific implementation. Also, the association should be in both ways, > i.e. also from the image profile document instance to the text profile > document instance. > > > > 1. Section 6 Supported Features and Extensions. All font-related > features are prohibited for the image profile. This seems to be an > unnecessary restriction if the image profile contains images in SVG format > which could be rendered differently based on the author’s choice of font > characteristics. > > > > 1. Section 7.7.3 itts:forcedDisplay. This seems like a temporary > solution. Wouldn’t it be better to define semantic layers of information > that each could be made visible and invisible at runtime as appropriate for > the user? For example, the user may want to see either speech-only > (subtitles), narration speech only (parts of subtitles), foreign-language > speech-only (parts of subtitles) or any combination of them. > > > > 1. Section 7.7.4 itts:altText. While we see this feature as useful > for accessibility purposes, it should be mandatory for images rather than > recommended only. As mentioned in the spec, one could take the pertaining > text passage from the text profile document instance – but (1) an > accompanying text profile is not required, and (2) the alternative text for > the image could be different from the textual caption. Therefore, the > itts:altText element should always be specified, but it should be empty for > decorative images (not clear if a “decorative image” used as a caption > makes sense anyway). By requiring an itts:altText for every image, but > allowing for an empty element in case of a decorative image, we would align > it with the alt attribute in HTML5 for images. > > > > </draft-feedback> > > > > Best regards, > > Gottfried > > > > -----Ursprüngliche Nachricht----- > Von: Accessible Platform Architectures Working Group Issue Tracker [mailto: > sysbot+tracker@w3.org] > Gesendet: Mittwoch, 18. Oktober 2017 09:29 > An: public-apa@w3.org > Betreff: apa-ACTION-2152: Review ttml profiles for internet media > subtitles and captions 1.1 https://www.w3.org/tr/ttml-imsc1.1/ > > > > apa-ACTION-2152: Review ttml profiles for internet media subtitles and > captions 1.1 https://www.w3.org/tr/ttml-imsc1.1/ > > > > http://www.w3.org/WAI/APA/track/actions/2152 > > > > Assigned to: Gottfried Zimmermann > > > > > > > > > > > > > > > > > -- *John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com
Received on Friday, 30 August 2019 15:26:12 UTC