Re: Moving personlization forward - wording suggestion

Hi AlastairI think this may be easier to discus on the call, but let me try and answer them here


The first bullet  can gives a loop whole in some cases and can be more work then the second bullet in other cases - but it serves two purposes. Firstly it means there is no requirement to add more semantics. The last time this issue was discussed some members felt strongly that we can not expect people to add semantics reliably. So if you can not do it, you can copy and paist a script or have an alternative version. Secondly, every platform will support it. So overall, between the two bullet points it is possible for everyone to conform - even if it is easier to do so in html/xml based languages. Thirdly, even though we have found other supporting techniques, it is easier to do the second bullet point using the coga -semantics. However people are uncomfortable depending on it. SO the first bullet point clarifies to everyone that there is no dependency on coga semantics to conform to the SC.


But in a summary, the point here is to get something in here, and build it up more in the supplement. We are trying to be innovative how we can get something in here on this issue. I am happy to here other directions that address all the comments.


In terms of the other issues. I see the definition of common elements listing some of the values of coga-action, coga-field  and coga-destination, so it should be very well defined what you need to include. Also this makes comments on other aspects of the specification a bit out of scope in this discussion. (BTW I think your other comments on the speck are important  - I will try to find out were we should be logging them as part of the ARIA work, but i do not want to divert this thread to a technical conversation on sematics).


Let me know what I missed


All the best
Lisa


The first bullet could be satisfied with a button on the page that adds icons to two links. It is a loophole for people who want to do the minimum. Also, for those with good intentions there is no apparent scale of what *should* be done. I.e. include everything from the coga-personalisation spec, or just a sub-set?


Some of the coga-personalisation spec is defined in a similar way to ARIA where there are clear ways to apply it. However, some is very open (e.g. coga-context) and there is no concrete guidance for how or when to apply it. 
You would have arguments like “I think the context should be gender-based” whilst someone else thinks it should (also) be location based, with no way to resolve those arguments.
Those parts of the spec are not a suitable basis for a WCAG SC, although they could be provided elsewhere.


Achieving personalisation with the 1st bullet (on-page) appears to be more work than with the 2nd bullet (meta-data only), as you would have to define the context for both, AND then build the mechanism for the page. 
Why have the 1st bullet?


It is not clear if the author is responsible for what happens when a user applies their own icons (expanding the links). Just applying meta-data is one thing, but in practice that will fall apart if there is no specification for what should happen when it’s used.


There does not appear to be any user-side technology to use this yet. I followed the BBC link but hit a dead-end, it appears the company no longer produces an icon-browser.



---- On Tue, 04 Jul 2017 17:55:27 +0300 Alastair Campbell<acampbell@nomensa.com> wrote ---- 

      HI Lisa,
  
 It misses several of the points I raised last week [1, 2], I’ll try to make a simpler list here:
  
  The first bullet could be satisfied with a button on the page that adds icons to two links. It is a loophole for people who want to do the minimum. Also, for those with good intentions there is no apparent scale of what *should* be done. I.e. include everything from the coga-personalisation spec, or just a sub-set?
 
 
Some of the coga-personalisation spec is defined in a similar way to ARIA where there are clear ways to apply it. However, some is very open (e.g. coga-context) and there is no concrete guidance for how or when to apply it. 
 You would have arguments like “I think the context should be gender-based” whilst someone else thinks it should (also) be location based, with no way to resolve those arguments.
 Those parts of the spec are not a suitable basis for a WCAG SC, although they could be provided elsewhere.
 
 
Achieving personalisation with the 1st bullet (on-page) appears to be more work than with the 2nd bullet (meta-data only), as you would have to define the context for both, AND then build the mechanism for the page. 
 Why have the 1st bullet?
 
 
It is not clear if the author is responsible for what happens when a user applies their own icons (expanding the links). Just applying meta-data is one thing, but in practice that will fall apart if there is no specification for what should happen when it’s used.
 
 
There does not appear to be any user-side technology to use this yet. I followed the BBC link but hit a dead-end, it appears the company no longer produces an icon-browser.
  
 Overall, rather than trying to get ‘something’ in and then throwing *everything* in, we need to take a similar approach to other areas of the W3C in moving the platform forward (as Chris, David and Jason have said in several ways). That means starting with a focused set of things to achieve.
  
 I recommended removing the first bullet and focus on a 1.3.1/4.1.2 approach for the remaining requirements, so essentially relying on the personalisation spec for the details.  That brings me back to a previous suggestion [3]:
  
 “1.3.x Contextual information: Where a defined vocabulary is available, contextual information can be programmatically determined for sections and controls.”
  
 However, for that to work the spec will need to remove the ‘open’ classifications as they are too subjective to form a basis for testing. 
  
 Kind regards,
  
 -Alastair
  
 1]  https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1356.html 
 2]  https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1360.html
 3]  https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1345.html