Re: Possibility of moving Personalization Semantics out of ARIA and into APA

Hi Lisa,

I think there is a fundamental difference between what ARIA seeks to
accomplish, and what the Personalization work is setting out to do. With
ARIA, we have a number of attributes and values that map, one-to-one, with
existing Accessibility APIs. Yet the Personalization work is increasingly
reliant on something fundamentally different: a rich metadata taxonomy. I
personally see the difference as between "what" versus "why".

ARIA-like notation *might* be one way of solving the larger Personalization
problem, but there is some evidence to suggest it may not be: the original
proposal that came forth from the working group saw originally a large
(most said "too" large) collection of newly proposed ARIA attributes. That
approach was widely criticized (around the same time-frame as TPAC 2015 in
Sapporo) as being to onerous and too confusing to content owners and
authors. That then morphed to a collection of coga-* attributes, that many
felt suffered the same basic issues. The latest Personalization draft has
again replaced the coga-* notation with the more recent aui-* notation, and
a significantly fewer number of attributes. Some are questioning if even 6
or 7 new attributes are too much however, and more importantly , the latest
draft is looking at other means of attaching the metadata to content (above
and beyond aui-* notation, such as Microdata, JSON, and RDF / RDFa).

I see these advances as positive steps, and in discussion with many,
working on the rich taxonomy of metadata values (and issues related to
globally sharing that taxonomy) is and remains the greatest task, and the
mechanism for attaching that metadata is something that can and will be
worked out as our taxonomy gets firmer.

By moving this Personalization work from out under the ARIA Working Group,
it will actually free the group to be more 'creative' - we are not tied to
the need of using more attributes, nor of ARIA-style notation. It gives the
Personalisation activity more latitude, but (and this is the more important
part, IMHO), by moving it under APA, it ensures that the same level of
support from the W3C remains in place.

Lisa, at the end of the day, I think what is more important is to continue
getting this work done. Which (virtual) office building we enter, or
(virtual) desk we sit at, is, for the most part, secondary to the larger
goal of continuing forward movement. I see that commitment in the proposal
to decouple Personalization from the ARIA WG and move that Task Force to
the APA WG - it should have very little impact on the day-to-day activities
of the TF, and it is a firm commitment (including the financial support)
from the W3C to continue moving forward.

I see this as nothing more than a procedural re-org, to better align the
work to what is actually happening day-to-day.

JF

On Sun, Apr 8, 2018 at 5:50 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:

> Hi Joanie
>
> I am not sure what the methodology in deciding these criteria and
> definitions. They were  not the original intention of ARIA. (I wrote the
> first drafts.) Originally ARIA was to add semantics needed for
> accessibility that were missing. To solve the problems and roadblocks for
> inclusion.
>
> In fact in the meeting in Germany (I think it was in 2006) we had some of
> the personlization semantics included. We decided to  postpone the
> cognitive part and focus on the impact on screen reader users first as it
> was an easier problem to solve. We voted and resolved to work on the
> context for cognitive AT as soon as the problem of dynamic interfaces and
> screen readers was solved (more or less). To overturn this resolution is to
> decide for aria to exclude cognitive after people from that community put
> in a lot of resources, in part, to help us get to the next stage.
>
>
> 1. ARIA does not control what content will be loaded - this is true also
> for personlization semantics
> 2. ARIA does not impact how loaded content will be displayed. - this is
> not always true. It effects the UI, and  can impact what is shown and
> hidden when things will be read and the tab order etc.  In a similar way to
> personlization semantics.
> 3. ARIA information is conveyed via accessibility APIs. Again I am not
> sure this is not always true. Sometimes we are leaders and the APIs move to
> meet us. in this case we are enabling new generation of accessibility
> support and it may well be in the future that accessibility apis map to
> what we are doing. I am not sure this works with epub module etc.
>
>
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Fri, 06 Apr 2018 00:58:26 +0300 *Joanmarie
> Diggs<jdiggs@igalia.com <jdiggs@igalia.com>>* wrote ----
>
> Hi Personalization Semantics Task Force members.
>
> As you may be aware, the charters of the ARIA and APA Working Groups are
> each about to expire. As part of the re-chartering process, both Working
> Groups need to identify their proposed deliverables. Personalization
> Semantics is currently listed as a deliverable of the ARIA Working
> Group, and we believe it would be a better fit for everyone as an APA
> deliverable.
>
> First and foremost are the technical aspects of implementation. In
> particular:
>
> 1. ARIA does not control what content will be loaded.
> 2. ARIA does not impact how loaded content will be displayed.
> 3. ARIA information is conveyed via accessibility APIs specific to
> individual platforms through mappings specs ("AAMs").
>
> In other words, ARIA does not impact the experience of sighted users.
> This is by design. And it seems to be the opposite of what is described
> in the Personalization Semantics Explainer [1]. For instance, in section
> 1.1 ("Why We Need Personalization"), it says the following:
>
> Some users need extra support. This can include:
> * Symbols and graphics that they are familiar with
> * Tooltips
> * Language they understand
> * Less features
> * Separating advertisements, so they do not confuse them with native
> content
> * Keyboard short cuts
>
> In order to address those needs, the experience of sighted users is
> necessarily impacted: Personalization by definition is to make
> determinations regarding what gets included on screen, what gets
> excluded, and how rendered content should appear. ARIA does not do that.
>
> Furthermore, achieving the Personalization needs listed above does not
> require the behind-the-scenes information consumed by platform-specific
> assistive technologies. You should be able to achieve Personalization
> Semantics support much more quickly and easily than ARIA -- and in a way
> that works in all operating systems -- via browser extensions. Indeed
> there is already at least one proof of concept demonstrating this.
>
> It also seems that using ARIA-style states and properties is only one
> proposed method of implementing the desired outcome. The Personalization
> explainer lists HTML microdata and RDF/A as other potential
> implementation techniques. Having this specification within the ARIA
> working group seems to unnecessarily require an ARIA-style
> implementation which may not be the best outcome for the specification.
>
> That said, Personalization Semantics is an essential module and a key
> part of WAI and needs a home. If that home is not within the ARIA
> Working Group, where should it be? We do think Personalization Semantics
> can benefit from the support of being housed within an existing WAI
> Working Group so that those working on achieving it can focus on doing
> so. That, combined with the fact that APA is considering including
> normative deliverables in its upcoming charter, makes us think that APA
> would be a much better fit for continuing this work.
>
> Please let us know your thoughts on this matter. Thanks!
> --Joanie and James
>
> [1] https://www.w3.org/TR/personalization-semantics-1.0/
>
>
>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion