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

I think that Alastair’s approach points in the the right direction.

Are there any implementations of the COGA Semantics to Enable Personalization that can be looked at / tried out and that would show the benefits of, four example, adding icons via coga-action or coga-destination?
I have looked at a few places but linked to from the draft spec (wiki page, github page) and found code, but not pointers to anything that looked like a simple demo. (I think I do have seen one before that I did not really understand but can’t find the link now.)

If, as Lisa says, the new coga attributes are in principle easy to implement for common actions and destinations on common sites, it should be easy to demonstrate their use on some average sites representing real-world types of content (news, a typical company web site, simple transactions etc.) Perhaps that proof of concept type stuff has already been done? I would like to be more convinced that working with the coga ARIA extensions would work for people with cognitive disabilities. If workable examples exist, they would allow us to define simple activities and test them with users with different kinds of disabilities in the context of two projects that both have a strong element of user testing with people with various disabilities: a current one, COMPARE http://www.funka.com/en/projekt/compare/ and an upcoming one that has been approved but has yet to be finalised.

Best, Detlev
 
> On 30 Jun 2017, at 01:05, Alastair Campbell <acampbell@nomensa.com> wrote:
> 
> 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:
> 
> Use regions to identify the purpose of areas of the page (with both ARIA regions and the extensions from [1]
> Use ‘coga-action’ to provide context for buttons when the purpose of the button matches the spec [2].
> Use ‘coga-destination’ to provide context for links when the purpose of the link matches the spec [3].
> 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 <https://w3c.github.io/personalization-semantics/#potential-parts-of-a-page>
> 2] https://w3c.github.io/personalization-semantics/#desc-coga-action <https://w3c.github.io/personalization-semantics/#desc-coga-action>
> 3] https://w3c.github.io/personalization-semantics/#desc-coga-destination <https://w3c.github.io/personalization-semantics/#desc-coga-destination>
> 4] https://w3c.github.io/personalization-semantics/#desc-coga-field <https://w3c.github.io/personalization-semantics/#desc-coga-field>
>  
> 
> From: John Foliot [mailto:john.foliot@deque.com <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.
> 
>  
>