- From: lisa.seeman <lisa.seeman@zoho.com>
- Date: Tue, 27 Jun 2017 09:47:33 +0300
- To: John Foliot <john.foliot@deque.com>
- Cc: "Alastair Campbell" <acampbell@nomensa.com>, "W3c-Wai-Gl-Request@W3. Org" <w3c-wai-gl@w3.org>
- Message-Id: <15ce84c4694.d207295486658.4564427137736617147@zoho.com>
The suggestion is to make more ways to conform (that was what was vague) not to make it vague whether you conform
All the best
Lisa Seeman
LinkedIn, Twitter
---- On Tue, 27 Jun 2017 01:40:12 +0300 John Foliot<john.foliot@deque.com> wrote ----
> But maybe we should make the first bullet point vaguer and only require that "some" none essential content or non-core content can be removed. That way people can be sure they conform.
Hi Lisa,
I'm sorry, but I cannot accept that position at all.
Standards, and specifically here WCAG Success Criteria, aren't designed to be "vague" - on the contrary they are supposed to be specific and testable: that is why they are called Standards.
As a 3rd-Party tester, I cannot be assuming or presuming to know what either the content author or the end-user deems "core" (essential), and "non-core" (not essential), and weakening SC language so that more sites "...can be sure they conform" misses the point by miles. I cannot support this thrust of reasoning at all.
> Core is defined as: the minimum functionality and content that is needed for users to identify the topic and fulfill the purpose of the content.
Which user should I select when assessing this proposed SC?
The problem with this definition is that there is nothing measurable there: the whole point of what you are attempting to do here is level the playing field for individual users, and yet what is "core" for some users will likely be overload for others, but we have no measure of who meets which needs-requirement
Without an identified and measurable bench-mark, this SC is reduced to a hand-wavey Best Practice that is easy enough to explain in principle, but significantly harder to implement.
3 key things to remember when writing proposed Success Criteria:
Make testable statements
Every Success Criterion needs to be testable. A web accessibility professional should be able to determine whether the content passes or not with a "high degree of confidence".
It is possible to evaluate the Success Criteria independent of the user who is consuming it
The author doesn't know who the end user is going to be. So a Success Criterion can't describe the user's experience, because that may differ among end users. Instead, it is important to tease out the underlying properties that will permit (but not guarantee) that the user will have a good experience.
Describe the affirmative condition of the passing content
Success criteria describe the state of the content, not the process for creating it.
(source: https://www.w3.org/WAI/GL/wiki/What_are_Success_Criteria,_and_how_to_write_them)
That last bullet is critical. The need for personalization is, I think, pretty much understood within this working group, and I don't think anyone disagrees that there is a need here. However, this SC seems very much being written to codify processes (use a script like that from User1st, or add a large number of meta-data attributes inline taken from a Draft W3C Recommendation that is not yet complete).
> "The thing to remember here is we prefer the second option..."
Advancing a Success Criteria that essentially mandates the use of an immature and not-yet-standardized technology won't fly, and previous arguments drawing comparisons to ARIA aren't enough. None of the original WCAG 2.0 Success Criteria required the use of ARIA - yes, using ARIA to meet some of those SC is the easiest and best path forward - but NONE of them requires ARIA to achieve success.
We cannot now try to use a proposed WCAG Success Criteria to strong-arm the use of additional tech, which appears (to me) to be the larger goal here.
JF
On Mon, Jun 26, 2017 at 2:35 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
I think we can say if users are likely to have gone to a page to use or find this content then it is core content.
But maybe we should make the first bullet point vaguer and only require that "some" none essential content or non -core content can be removed. That way people can be sure they conform.
The thing to remember here is we prefer the second option - However, we doubt we can get it in by itself as it requires people to add more semantics. The the first option helps the user a bit, and is a way to get in personalization. There will be some sites using the second bullet point and that will increase, by an order of magnitude, the amount of content that is usable by people who understand a limited set of symbols (and prefer them to words). It will introduce accommodating them as an option.
We are just setting floor here - not the ceiling. But in this case it will still have a huge impact
It would be great if you could think of a better suggestion.
All the best
Lisa Seeman
LinkedIn, Twitter
---- On Mon, 26 Jun 2017 14:32:30 +0300 Alastair Campbell<acampbell@nomensa.com> wrote ----
Hi Lisa,
Hiding things isn’t hard, people have been doing a similar thing for different reasons for years with print style sheets.
However, there are two things I don’t understand from a feasibility point of view:
1. How does an author (or external tester of a site) define what is “core”?
For example, the BBC homepage is full of stuff, but they have millions of users with different neds & expectations. I might go there for the weather and it’s answered on the homepage. Others are there for the news, others for iPlayer. These are all ‘core’ to someone. The BBC also allows you to personalise (change what content is shown) on the homepage.
The definition assumes there is one “purpose of the content”, which is rarely true for a site of significant size. This isn’t just a homepage problem either, it applies throughout most sites unless you get into a particular journey (e.g. checkout process), or the site is very focused.
I think the fundamental problem is that if the site owner knew what was core at any particular point, they would reduce the options to that. It is only because they don’t know that there is so much stuff on the page!
2. Whose responsibility is it for added icons to work?
If a site adds the meta-data so that a user can add icons, is the site responsible for testing that they don’t break the layout or functionality?
Looking through the proposed semantics [1] and trying to apply that to a website like www.theguardian.com, I’m struggling to see how it would work.
The home, sign up, and “my profile” seem applicable, but each of these already has an icon. Would the user’s script be smart enough to replace instead of add icons? In which case it would have to understand an awful lot about how the site was put together. (There are too many ways to put icons on a page.)
If (as I would assume) the user’s script does not know about the layout of the site, how does the site know how much space to leave for the added icons? If it doesn’t allow for space, navigation layouts will break.
That adds another layer of browser & layout testing for the site with unknown boundaries.
-Alastair
1] https://w3c.github.io/personalization-semantics/#adding-context
From: "lisa.seeman" <lisa.seeman@zoho.com>
Date: Monday, 26 June 2017 at 10:07
To: Amihai Miron <amihai@user1st.com>, WCAG <w3c-wai-gl@w3.org>
Subject: How long /hard is it to install the personlization.
Resent-From: WCAG <w3c-wai-gl@w3.org>
Resent-Date: Monday, 26 June 2017 at 10:08
Hi Folks
Andrew had asked me about how much work it would be to add the personlization SC to a web site
I had a chat with Amihai from user first on Friday who gave it a dry run to conform to the currently proposed wording. He also made a script which he is happy for us to post as open source to help other people meet the current wording.
The entire process of creating such a script takes 15-60 minutes including testing it on a site. I can only assume once you have the script the process is much shorter...
There are now two open source scripts to help people. (Including a meta data based script that injects the semantics into a whole site and then injects the personlization.)
Links to his demo page and his script are bellow.
All the best
Lisa Seeman
LinkedIn, Twitter
---- 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
| m: +972-584-779-084
| f: +972-77-318-2012
| w: http://www.user1st.com
| Skype: amihaimiron
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
Received on Tuesday, 27 June 2017 06:48:07 UTC