Re: Personalisation semantics - naming

Ok, I’m coming at this fresh so please forgive me stumbling into old issues.

How about the point on gathering other attributes so we can use an name that is not disability specific?

I have a feeling that with a better view of the whole, we might be able to categorise some things as landmarks, some as personalisation attributes, perhaps some as html input types? If not, at least with all the potential attributes in one place we’d have a better idea for naming…

Cheers,

-Alastair


From: John Foliot <john.foliot@deque.com>
Date: Tuesday, 25 April 2017 at 17:00
To: Shwetank Dixit <shwetank@barrierbreak.com>
Cc: "lisa.seeman" <lisa.seeman@zoho.com>, Alastair Campbell <acampbell@nomensa.com>, "public-aria@w3.org" <public-aria@w3.org>
Subject: Re: Personalisation semantics - naming

Hi Alastair,

A HUGE -1 to returning to an ARIA prefix. This was discussed at length when we were at TPAC 2015 (Sapporo), and we emerged then with a decision to not "ARIA all the things". (I for one felt very strongly about this during the discussion)

The largest issue we'd encounter is push-back from the browser vendors.

This is because ARIA was "sold" to them as not requiring *any* changes to the UI or content rendered on-screen;  that aria-tagged content was *EXCLUSIVELY* for the Accessibility APIs. Given that one of the larger goals of all of the COGA efforts points to on-screen "personalization", if we were to use aria-* attributes then the browsers would demand that all of the personalization bits be performed by Assistive Technology, as (to them) that was the "WHY" of ARIA in the first place.

I would strongly oppose any contemplation of returning to aria-* prefixes for COGA personalization.

JF

On Tue, Apr 25, 2017 at 10:47 AM, Shwetank Dixit <shwetank@barrierbreak.com<mailto:shwetank@barrierbreak.com>> wrote:
If it won't have integration into aria, then I would rather the names have a 'coga-' prefix than something like 'ariap' because thats too similar to aria and will create confusion and unnecessary typos and errors.

I think coga is fine, but if, as Alistair suggests, people from the lvtf or other groups could add to it, then maybe we could have a different prefix.


On 25 April 2017 at 21:08:20, lisa.seeman (lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>) wrote:
I like these changes. We did start with the aria prefex but we got kickback becuse the aria prefex could  have bloat and  devlopers will be put off.

can you think of another prefex? such as ariap for aria persolization
All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>



---- On Tue, 25 Apr 2017 18:24:08 +0300 Alastair Campbell<acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote ----
Hi,

I’m commenting on the spec at https://w3c.github.io/personalization-semantics/


I have a few comments, but the main one is around the name of the attributes, the “coga-“ approach.

It appears many of these attributes would be useful to others (with keyboard short cuts for example), can we use one attribute type for all things accessibility?

If "aria-" were used instead of “coga-“ then ARIA is no-longer just a screen-reader thing (hooray!). If everything is aria- or role=, then developers won't be dividing up audiences in their mind, they are just applying general accessibility meta-data.

The less we can sub-divide the accessibility audiences, and the clearer the solutions are, the better traction it will get.

Working that through for the various attributes:

-          How about “aria-context” instead of “coga-action”?

-          aria-destination instead of coga-destination.

-          coga-field appears to cross over a lot with HTML5 input types, can it align with those?

-          aria-input instead of coga-field.

-          coga-context, seems easily confused by name, could it be aria-profile instead?

-          aria-icon instead of coga-concept.

-          coga-numberfree seems like it could be more generalizable, it is akin to the abbr element. How about aria-explained?

-          Could coga-literal also go under aria-explained?

-          coga-feedback feels very similar to aria-live in concept, but I can see the different audience requirement.
How about aria-feedback?
That’s just some ideas, but I also think it would help to include the attributes other audiences have (e.g. low vision, mobility), and come up with a more generalised categorisation.

I’m sure the AG working group’s low vision task force would be able to help with that (which I’m on), are there other groups that should be involved consulted?

Kind regards,

-Alastair

--

www.nomensa.com<http://www.nomensa.com/> / @alastc






--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion