RE: should we say "critical controls" or just "controls".

Hi Everyone,

After the call I’d like to re-iterate a main point I don’t think we had time to discuss, with a possible approach.

The first bullet “a mechanism is available for personalization of content that enables the user to add symbols to interactive controls OR”.
That could be fulfilled with a button on the page that adds an icon to the home link, which doesn’t really help.

The problem is that there is no defined of scale of what should be possible to personalise. Every control? Some of the properties have defined values (e.g. coga-destination), but some are very open (e.g. coga-context) with no guidance as to when they should be applied. (Nor can I see how you could provide that.)

It seems that the best way to approach it would be to take a 1.3.1/4.1.2 approach where we say that “context” (or something) should be applied.
Off-load the scale problem to the separate spec, as 1.3.1 off-loads it to HTML, and 4.1.2 to ARIA (when applicable, but if there is no suitable pattern then you don’t have to use it but probably need an alternative).

The problem is then that the coga-personalisation spec includes a huge amount of options, some of which are very open..

Taking ARIA landmarks as a similar concept to some of coga-personalisation, there are less than a dozen of them, and they have a direct and obvious impact on the user-experience for some people. Yet their usage is still far from common.

So, rather than get ‘something’ in that is huge and with a fall-back (which is also undefined in scope), let’s get the principle in (add context to regions and controls), and work on a focused and clear spec for the context.

It could do with some clean-up so we don’t replicate HTML input types, so you don’t get things like:
<input type="email" coga-field=”email”>

The sections I outlined as useful techniques do seem clear to me, but I recommend moving the completely open ones (e.g. coga-context) to a secondary spec. *If* the pre-defined ones work and get taken up, then bring in the open ones. That is a good ‘something’ to get in.

That also brings up the user-side of the equation:

  *   Are there any user-agents that can deal with this now, or are in development now?

I followed the link to the BBC page about an icon browser, but that got to a dead end, I think it has been disconinued. Searching for ‘icon insertion’ doesn’t help very much :-/

Cheers,

-Alastair


From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: 29 June 2017 13:54
To: John Foliot <john.foliot@deque.com>; lisa.seeman <lisa.seeman@zoho.com>
Cc: W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
Subject: RE: should we say "critical controls" or just "controls".


Sorry, I may have sent a draft version on this before, I was trying new email client.



I wonder if an alternative approach is to specify what content is, rather than how important it is? Then it’s upto the client to define importance for different things, not the site (or testers).



Trying to come at this from the techniques upwards, we would want things like:

  1.  Use regions to identify the purpose of areas of the page (with both ARIA regions and the extensions from [1]
  2.  Use ‘coga-action’ to provide context for buttons when the purpose of the button matches the spec [2].
  3.  Use ‘coga-destination’ to provide context for links when the purpose of the link matches the spec [3].
  4.  Use ‘coga-field’ to provide context for text inputs when the purpose of the field matches the spec [4].



 NB: coga-context doesn’t seem to have pre-defined options, not sure where to go with that one.



The first of those (regions) would be the basis for hiding areas of the page, and the 2nd – 4th would be for hiding particular controls or adding icons.



All of these are attributes rather than elements, so closer to 4.1.2 than 1.3.1, but these are not aimed at “Web authors who develop or script their own user interface components” so we need a new SC.



How about something like:

“1.3.x Contextual information: Where a defined vocabulary is available, contextual information can be programmatically determined for sections and controls.”



(Sections and controls already have definitions, not sure if “defined vocab” is a reasonable way to refer to another spec?)



I still think there is a huge problem with being able to add icons into a layout automatically, but this at least avoids the ‘essential/core’ problem, and means that if the associated spec isn’t ready, a page doesn’t need to conform to it.



Cheers,



-Alastair





1] https://w3c.github.io/personalization-semantics/#potential-parts-of-a-page


2] https://w3c.github.io/personalization-semantics/#desc-coga-action


3] https://w3c.github.io/personalization-semantics/#desc-coga-destination


4] https://w3c.github.io/personalization-semantics/#desc-coga-field




From: John Foliot [mailto:john.foliot@deque.com]

At that point, I honestly have to ask, are we really approaching this the right way? I am not convinced we are.