Does personalization semantics work as an ARIA module?

[michael-n-cooper]

When I submitted #50 I intended to include a description of how to use the personalization semantics vocabulary could be expressed as ARIA attributes. But as I thought about what the section would have to say I realized it would not work as currently conceived. Several other people have also asked about the structure with respect to ARIA, so I wanted to put a description of the issues in one place.

There are several challenges to implementing personalization semantics as an ARIA module:

1. The function of ARIA is to define semantics that map to Accessibility APIs. However, nearly all the features in personalization semantics do not map to AAPIs. I do not think we expect tools will access the semantics through accessibility APIs, so there would be no need or value in adding that layer to the mix. Unless we can make a compelling argument that accessibility API mappings are possible and needed, I don't think the ARIA WG will support this as an ARIA module.
2. Most of the personalization semantics properties require values. This means they would need to be implemented as attributes in ARIA / HTML. Currently we expect that would be done with the "aui" prefix like aui-action="compose". However, HTML does not permit attributes with this prefix. The use of attributes with the "aria" prefix took years to negotiate. In order to create aui attributes, we would need to convince the Web Platform Working Group to accept attributes with the "aui" prefix, which could be a long negotiation and ultimately not succeed. Alternatively we could try to convince the ARIA Working Group to allow us to use the "aria" prefix, but for the reason above I'm not sure that would succeed.
3. It might be possible to recast the personalization semantics properties into a form that does not require values. Then it would be possible to use them as values of an existing attribute like role, using the "aui" prefix in some form like role="aui-compose". But it would take some exploration to determine whether the role attribute is suitable for this. We could propose a new attribute for personalization, which has the advantage of only requiring one new attribute instead of an indefinite set, but that still has a long path. And this approach would only work if we can find a way to make all personalization features work without requiring values.

We will need to determine the resolution to those issues to be able to describe how to use personalization semantics as an ARIA module. If we are not able to address those issues, we will have to conclude that personalization semantics does not map to ARIA. Currently that leaves HTML Microdata as the most likely way to apply the vocabulary to content.

[johnfoliot]

FWIW, I personally prefer the idea behind Option 3, but with the option of exploring a new single attribute: "intent" (a cousin of, and similar to @ role). To my mind @ role defines the "what", where-as a new @ intent attribute would define the "why".

I think approaching WebPlat with the idea of a single new attribute would likely be openly received by that WG.

Additionally, if this TF proceeds on that path, I would then question whether this TF needs to remain working under the ARIA WG banner (perhaps being re-sponsored by APA or the AG WG?) - but that is a separate issue.

[joanmarie]

The other problem with using role is that role maps to something on platform accessibility APIs. Using it for other purposes raises two concerns in my mind:

1. Risk of breaking accessibility for assistive technology users.
2. We'll have to add all the new "roles" to an AAM which seems rather pointless since those new "roles" aren't even intended for ATs and thus don't need mappings; the mappings would just be to try to prevent the previous item.

I dig @johnfoliot's idea of a new property like intent. Neat suggestion!!

[johnfoliot]

Thanks Joanie, I believe that for personalization to really gain traction, we'll need to make it as simple and light-weight as possible for content authors to implement. I think that all of the use-case requirements associated to personalization can in fact be distilled down to "*What is this here for? What is the intent?*", and as such, I suspect at this time it could all be handled with a single attribute: the key of course is what *values* would be associated to the attribute (fixed list), and can all of the emergent requirements from COGA/Personalization be addressed that way? Given that the current direction is to publish a vocabulary of terms and definitions <https://w3c.github.io/personalization-semantics/content/index.html>, I believe we can still attach those values to the targeted element with a single attribute. For example: < button intent="action-undo"> (alternatively: <button intent="action.undo">? <button intent="action_undo">? ...specific notation TBD, but a notation that supports a compound thought is what would be required) < a href="" intent="destination-sitemap"> < input type="tel" intent="field-tel">, <input type="text" intent="field-postalcode"> < div intent="importance-critical">, < aside intent="importance-low"> < a href="video.mp4" intent="distraction-autoStarting">See my video here</a

(ya, this seems weak...) (I have not provided an example for the proposed 'symbol', as by the draft specification alone this doesn't make any sense to me - it is unclear what is being attempted here) At this time, this is all "off-the-top-of-my-head" thinking (without any deep research), but I hope to introduce this proposal to the Task Force, as well as attempt to chat-it-up next week at CSUN.

…

On Wed, Mar 14, 2018 at 2:06 PM, joanmarie ***@***.***> wrote: The other problem with using role is that role maps to something on platform accessibility APIs. Using it for other purposes raises two concerns in my mind: 1. Risk of breaking accessibility for assistive technology users. 2. We'll have to add all the new "roles" to an AAM which seems rather pointless since those new "roles" aren't even intended for ATs and thus don't need mappings; the mappings would just be to try to prevent the previous item. I dig @johnfoliot <https://github.com/johnfoliot>'s idea of a new property like intent. Neat suggestion!! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c4oF2go_F7YGPJEEhL8F-OTe_Hn7ks5teVwvgaJpZM4Sftir> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion