- From: lisa.seeman <lisa.seeman@zoho.com>
- Date: Fri, 30 Jun 2017 10:57:52 +0300
- To: Detlev Fischer <detlev.fischer@testkreis.de>
- Cc: "Alastair Campbell" <acampbell@nomensa.com>, "W3c-Wai-Gl-Request@W3. Org" <w3c-wai-gl@w3.org>, "public-cognitive-a11y-tf" <public-cognitive-a11y-tf@w3.org>
- Message-Id: <15cf7ffbe10.be4abaf34168.7142549103378025553@zoho.com>
HiThe link to the simple demo is https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html
I am also forwarding the email from User1st who integrated it into their platform in about 3 hours. Note this was for old wording so it would need to be changed to conform to the current version.
all the best
Lisa
---- On Mon, 26 Jun 2017 09:49:10 +0300 Amihai Miron<amihai@user1st.com> wrote ----
Hey Lisa,
A. Enables the user to add symbols to interactive controls for core functionality:
A. Go to :http://www.imss.gob.mx/transparencia/normatividad-fp
B. Select "asistencia" (help) profile
C. an ICON will appears near each download link (this is a customized icon, that a user could have created)
Please find the script to make this function work:
Script:
var image = "image url for download";
if($("._u1st_uniqueDownloadHelp").length < $(".glyphicon-download-alt").length)
{
$(".glyphicon-download-alt").after($("<img>")
.setAttr("src", image)
.css("margin-left","10px")
.css("width","50px")
.addClass("_u1st_uniqueDownloadHelp")
.setAttr("alt", "download")
);
}
(Note: The image base 64)
B: a mechanism is available for personalization of content that removes non-core functionality and content:
Hide specific section in help profile
A. Go to http://www.imss.gob.mx/
B. Select "asistencia" (help) profile
C. The section on the bottom will disapear
Script:
$(".pane-v-imss-numeros").closest(".inside.panels-flexible-row-inside.panels-flexible-row-2-2-inside").hide();
Summary - The entire process of creating such a script takes 15-60 minutes including testing.
Please let me know if that works for you.
Thank you,
Amihai
On Sun, Jun 25, 2017 at 3:59 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
Hi
On Tuesday the WCAG group will debate a proposal for personlization for wcag 2.1. We will have a week and a half to get it though.
the proposal is:
For pages that contains interactive controls or content that is not core, one of the following is true:
a mechanism is available for personalization of content that removes non-core functionality and content, and enables the user to add symbols to interactive controls for core functionality, or
core functionality and content, and contextual information for essential functionality and content, is programmatically determined.
The proposal is at https://github.com/w3c/wcag21/issues/6
Core is defined as:
the mimimum functionality and content that is needed for users to identify the topic and fulfill the purpose of the content
For example, core content is generally identified by the page title. Core functionality is that which is needed to fulfill the purpose described by the page title
contextual information is currently defined as :semantics and tags that give meaning to the content such as context of elements; concept and role; relevance and information for simplification; position in a process
Supporting semantics is proposed at https://w3c.github.io/personalization-semantics/
We need an example to show it as doable / useful including approximations how long it would take for authors to add the semantics.
Thanks for all your help
All the best
Lisa Seeman
LinkedIn, Twitter
--
Amihai Miron
CEO User1st
All the best
Lisa Seeman
LinkedIn, Twitter
---- On Fri, 30 Jun 2017 08:39:35 +0300 Detlev Fischer<detlev.fischer@testkreis.de> wrote ----
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
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.
Received on Friday, 30 June 2017 07:58:29 UTC