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

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