Re: 48-Hour Call for Consensus (CfC): New APA Charter

Thanks John, including for the very prompt response!

Janina

John Foliot writes:
> Hi Janina,
> 
> > In fact the reason that Personalization became an ARIA, rather than an
> APA Task Force during our last round of rechartering--as PF was split into
> two WGs--is precisely the understanding that the likely solution would be
> based on ARIA.
> 
> ​...which partially answers​ one of your later questions: I supported
> moving from a proliferation of aria-* attributes to newly proposed coga-*
> attribute(s) in 2015, because under the ARIA Work, it was all about
> attributes (there did not appear to be any other way out at that time).
> 
> ​My understanding now however, 3 years later, is that the current chair of
> the ARIA WG, along with others, have come to question whether that was the
> right approach, and in fact one of the reasons for moving Personalization
> out of the ARIA WG was to open up the possibilities of other non-attribute
> solutions (as suggested by Lisa and Michael back in 2015), and more
> recently by Sam Goto of Google, who I was able to convince to come join
> this effort. Sam is not an accessibility person, he is a Google engineer
> with a deep knowledge of meta-data, personalization with regard to search,
> and is currently attached to the Chrome Dev team, and he too has asked
> about different mechanisms to achieve these goals.​
> 
> I believe this is also in keeping with Katie Haritos-Shea's comments that
> Personalization is (should be) bigger than just accessibility, and that we
> need to be involving more voices in this pursuit. I believe that moving
> Personalization TF under APA frees that TF to do that further exploration,
> investigating CSS approaches, HTML5 approaches (Leonie suggested the one or
> two attributes approach that Michael has documented, which would require
> assistance from the Web Platform WG), and lower-level API +
> JavaScript/Polyfill approaches (Sam). It is against those understandings
> that I remain concerned that the Modules continue to reference
> attribute-based solutions.
> 
> 
> > The relevant language that IS in the current APA Charter draft
> covering normative Personalization specification work is in the "Scope"
> section and reads:
>         "Leverage existing W3C markup technologies to produce new
>         specifications which support content personalization for various
>         identified accessibility requirements;"
> 
> 
> Precisely, and yet, instead we seem to be being offered a new prefix and
> 18+ new attributes. Again, the examples in the Modules contradict the Scope
> as you have indicated above.
> 
> 
> > Do these disclaimers help?
> 
> ​Stepping back and recognizing time constraints and deadlines, I agree that
> those disclaimers (once the final module is "cleaned up" - per Thaddeus)
> will ​be minimally sufficient.
> 
> 
> ​> It is very much a work in progress and likely to remain so for some
> time. We do hope you and Deque can help make its outcomes useful to an
> ever widening circle of both developers and end users.​
> 
> ​Indeed, and it is my hope that my questioning here is in fact​ a sign that
> I for one, and Deque as a whole, want to ensure that not only do we get
> this done, but that we get it done right.
> 
> 
> > I'm hoping we can find the resolution that could get Deque from a -1 to a
> +1 on the APA Charter.
> 
> ​Having articulated the concerns and getting them into the public record,
> coupled with the fact that many of those concerns have been acknowledged
> and steps have been taken to mitigate many of them, I think that the
> Charter can advance now without further issue.​
> 
> JF
> 
> 
> 
> 
> On Thu, May 17, 2018 at 3:13 PM, Janina Sajka <janina@rednote.net> wrote:
> 
> > Hello, John:
> >
> > I will endeavor to keep this email succinct. I'm hoping we can find the
> > resolution that could get Deque from a -1 to a +1 on the APA Charter.
> >
> > For the record I want to acknowledge you did try phoning me earlier in
> > the week. And, while I'm aware you're currently engaged with Access U,
> > if there's any opportunity for a conversation before close of business
> > Friday, I will be available to you.
> >
> >
> > I have just a few comments below in response to your comments here, but
> > also from your post at:
> > http://lists.w3.org/Archives/Public/public-apa/2018May/0017.html
> >
> >
> > John Foliot writes:
> > > - 1.
> > >
> > > Deque supports the ongoing work of the APA WG, as well as moving the
> > > Personalization Task Force from the ARIA WG to the APA WG. Our concern is
> > > with the Rec Track Modules defined in the Charter deliverables.
> > >
> > Thank you for the overall support for APA.
> >
> > > We have serious reservations regarding the emergent approach of an
> > > attribute-based taxonomy solution, which, despite assurances to the
> > > contrary, is what is being proposed and illustrated in the current 3
> > draft
> > > modules. This remains fundamentally the same approach that has been
> > > proposed since at least TPAC Sapporo (2015), where a number of
> > > accessibility people pushed back hard on the "ARIA all the things"
> > approach
> > > then. Moving the same basic idea to first coga-* attributes, and then
> > aui-*
> > > attributes is simply a reformulation of the original problem using any of
> > > these different attribute prefixes: author lift.
> > >
> >
> > You're indeed correct that this approach goes back at least to PF
> > discussion in October 2015 during TPAC in Sapporo.
> >
> > And, I do find you on record expressing concern about the proliferation
> > of ARIA attributes during those discussions:
> > http://www.w3.org/2015/10/26-aria-minutes.html#item07
> >
> > However, you also appear to have supported an ARIA prefix approach to
> > supporting the personalization requirements raised by COGA:
> > http://www.w3.org/2015/10/27-aria-minutes.html#item04
> >
> > In fact the reason that Personalization became an ARIA, rather than an APA
> > Task Force during our last round of rechartering--as PF was split into two
> > WGs--is precisely the understanding that the likely solution would be based
> > on ARIA. However, the current ARIA Charter, still the operative charter for
> > the Personalization TF, doesn't define this approach. Rather, it's stated
> > in the Personalization TF Work Statement:
> > https://www.w3.org/WAI/ARIA/task-forces/personalization/work-statement
> >
> > Should the W3C approve moving Personalization from ARIA to APA, we
> > would,
> > of course, be updating this Work Statement.
> >
> > The relevant language that IS in the current APA Charter draft
> > covering normative Personalization specification work is in the "Scope"
> > section and reads:
> >
> >         "Leverage existing W3C markup technologies to produce new
> >         specifications which support content personalization for various
> >         identified accessibility requirements;"
> >
> > I do not believe it would be appropriate for a Working Group charter to
> > be more specific. Certainly the Charter should not predetermine some
> > particular outcome. I believe the above language requires the TF to look
> > at all available markup from W3C in devising its normative
> > specifications. That would, of course, include ARIA, but would not be
> > restricted just to ARIA as is currently the case.
> >
> > I hope this helps on this point.
> >
> > > "Leaving them in" the Editors Draft (so that we remember what we're
> > talking
> > > about) is not the right answer, because it continues to leave the
> > > un-informed observer with the over-arching idea that we're working on new
> > > attributes. Nothing in the Charter or emergent modules suggests
> > otherwise.
> > >
> >
> > As you acknowledged on your other email thread:
> > http://lists.w3.org/Archives/Public/public-apa/2018May/0017.html
> >
> >
> > We have added disclaimers to the Personalization TF publications in the
> > hope of clarifying precisely this point. We have also made it easy to
> > access these disclaimers, e.g.
> >
> > https://w3c.github.io/personalization-semantics/
> > content/#examples-disclaimer
> >
> > Do these disclaimers help?
> >
> > > Finally, as others have noted, where is the compare and contrast of
> > > approaches we should have before we continue to pursue a specific
> > strategy?
> > > One of the advantages of moving this Task Force away from the ARIA WG was
> > > to free the TF to explore options beyond an attribute-based solution.
> > >
> >
> >
> > Of course, we need to do that work. However, please recognize the
> > Personalization TF is still under the ARIA Charter. Furthermore, while
> > our expectation of doing this work goes back at least to TPAC in Sapporo
> > as noted above, the Personalization TF was actually constituted far more
> > recently. It's Work Statement dates its work to 14 July 2017--less than
> > a year ago.
> >
> >
> > It is very much a work in progress and likely to remain so for some
> > time. We do hope you and Deque can help make its outcomes useful to an
> > ever widening circle of both developers and end users.
> >
> > Let me know if I can help further on the APA Charter.
> >
> > Janina
> >
> > > JF
> > >
> > >
> > > On Tue, May 15, 2018, 5:05 PM Janina Sajka <janina@rednote.net> wrote:
> > >
> > > > +1
> > > >
> > > > Janina Sajka writes:
> > > > > Colleagues:
> > > > >
> > > > > This is a Call for Consensus (CfC) to the Accessible Platform
> > > > > Architectures (APA) Working Group on a new Charter for our WG. As you
> > > > > know, our current Charter will expire at the end of July, and the
> > first
> > > > > step in the renewal process is for us to agree on the Charter
> > proposal
> > > > > we would offer to W3C.
> > > > >
> > > > > Having discussed a new Charter over the past several months, our
> > > > > proposed new Charter draft can be found here:
> > > > >
> > > > > https://www.w3.org/2018/03/draft-apa-charter.html
> > > > >
> > > > > It is hereby proposed to forward this draft Charter as our proposal
> > of
> > > > > work for the coming 3-year Charter period.
> > > > >
> > > > >
> > > > > *       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, Tuesday 15 May.
> > > > >
> > > > > Janina
> > > > >
> > > > >
> > > > ------------------------------------------------------------
> > ------------------
> > > > >
> > > > > 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 [1]TTML Profiles for Internet Media
> > > > >        Subtitles and Captions 1.1 is depending on [2]Timed Text
> > Markup
> > > > >        Language 2 (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:
> > > > >
> > > > >     a. Why are profiles needed for text-only and image-only
> > > > >        captions/subtitles?
> > > > >     b. What are typical use cases for a image-only
> > captions/subtitles?
> > > > >     c. What is the purpose of a presentation processor, and a
> > > > >        transformation processor?
> > > > >
> > > > >
> > > > >     2. 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.
> > > > >
> > > > >
> > > > >     3. Section 2 Documentation Conventions (applies also to [3]Timed
> > Text
> > > > >        Markup Language 2 (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. [4]WCAG 2.0 SC 1.4.1).
> > > > >
> > > > >
> > > > >     4. 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.
> > > > >
> > > > >
> > > > >     5. 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.
> > > > >
> > > > >
> > > > >     6. 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.
> > > > >
> > > > >
> > > > >     7. 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 [5]https://www.w3.org/tr/ttml-imsc1.1/
> > > > >
> > > > >
> > > > >    [6]http://www.w3.org/WAI/APA/track/actions/2152
> > > > >
> > > > >
> > > > >    Assigned to: Gottfried Zimmermann
> > > > >
> > > > > References
> > > > >
> > > > >    1. https://www.w3.org/TR/ttml-imsc1.1/
> > > > >    2. https://www.w3.org/TR/ttml2/
> > > > >    3. https://www.w3.org/TR/ttml2/
> > > > >    4.
> > > > https://www.w3.org/WAI/WCAG20/quickref/#visual-audio-
> > contrast-without-color
> > > > >    5. https://www.w3.org/tr/ttml-imsc1.1/
> > > > >    6. http://www.w3.org/WAI/APA/track/actions/2152
> > > >
> > > >
> > > > --
> > > >
> > > > 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
> > > >
> > > >
> > > >
> >
> > --
> >
> > 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
> >
> >
> 
> 
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
> 
> Advancing the mission of digital accessibility and inclusion

-- 

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

Received on Thursday, 17 May 2018 21:50:13 UTC