- From: Mary Jo Mueller <maryjom@us.ibm.com>
- Date: Wed, 8 Feb 2017 14:52:46 -0600
- To: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>, "Jeanne Spellman" <jspellman@spellmanconsulting.com>
- Message-Id: <OFBF41B757.FBA9EABB-ON862580C1.00724073-862580C1.0072B20B@notes.na.collabserv.c>
I really appreciate this whole discussion which speaks to how difficult it
is to "standardize" solutions into success criteria. Having been on the
receiving end of varying interpretations of requirements even in the
current version of WCAG, we have to be very mindful of the potential of
this happening on the new SC proposals.
Best regards,
Mary Jo
Mary Jo
Mueller
Accessibility
Standards
Program
Manager
IBM
Accessibility,
IBM Research,
Austin, TX
Phone:
512-286-9698 |
Tie-line:
363-9698
Search for
accessibility
answers
"If your actions inspire others to dream more, learn more, do more and
become more, you are a leader."
~John Quincy Adams
From: Michael Pluke <Mike.Pluke@castle-consult.com>
To: "lisa.seeman" <lisa.seeman@zoho.com>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>,
"Jeanne Spellman" <jspellman@spellmanconsulting.com>
Date: 02/08/2017 11:00 AM
Subject: Re: Proposals for revision of the Plain Language SC proposals
for WCAG 2.1
Hi Lisa
Only one of the examples I quoted was explicitly part of an exception. But
in any case, there is no such thing as "only exceptions". Exceptions are
just as important as the rest of the SC as they are supposed to make the
scope of applicability clear and indicate when the SC does not have to be
met.
I understand your point about 1.1.1's "equivalent purpose" text and that
there is definitely no absolute way to say that the text is equivalent.
However, like many other tests, it is extremely easy to identify the most
likely failures e.g. when the alt text says "Default text". All of the
examples I listed are much more difficult to get evaluator agreement on. So
I really don't think people are intentionally applying different standards
to exclude the COGA proposals. They are afraid of the arguments, disputes,
and potential legal action that could arise because of the difficulty on
agreeing if these difficult conditions have been met.
I agree with you on the reading age/navigation issue.
Best regards
Mike
Get Outlook for iOS
_____________________________
From: lisa.seeman <lisa.seeman@zoho.com>
Sent: Wednesday, February 8, 2017 4:19 pm
Subject: Re: FW: Proposals for revision of the Plain Language SC proposals
for WCAG 2.1
To: Michael Pluke <mike.pluke@castle-consult.com>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>, Jeanne
Spellman <jspellman@spellmanconsulting.com>
Hi Mike
I agree we should do everything we can to reach the bar. I do not think
they need to be more testable then the WCAG requirement or then the current
WCAG 2.0 SC.
The base criteria (not the exception) is 100% testable. The untestable
parts you said are only exceptions.
The bench mark for human testability is that 8 out of 10 experts in the
topic are reasonably confident. If 8 out of ten accessibility testers would
not agree that it is clearer or using a more common word may results in a
loss of clarity then use the more commen word. It has to be completely
obvious that this is clearer and easier to understand before you use an
exception. That is exactly what we want
The base criteria (not the exception) is 100% testable
note that in many success criteria in wcag part of it is testable and part
is less so. For example in 1.1.1 an alt tag needs to serve the same
function or purpose as the image.
In fact it never can because part of the images role is aesthetics. When
it first came out you did not often had consensus about the full 1.1.1 was
fulfilled. You could get consensus easily whether there was an alt text.
But that is all that is fully testable and that is not what wcag requires.
We do not need to be more testable then wcag 2.0. If the rules are unevenly
applied, that that seems unfair to me. Also I realy do not think there is
much to be gained by a low reading age on navigation. the formula will not
work on these case.
All the best
Lisa Seeman
LinkedIn, Twitter
---- On Wed, 08 Feb 2017 15:42:12 +0200 Michael Pluke <
Mike.Pluke@castle-consult.com> wrote ----
One thing I forgot to add to my lengthy email below is that I am not
suggesting that we completely replace #24 with what I proposed and then
forget about all of the other good stuff. My suggested way forward is to
break down these mega-SCs into smaller SCs that might be acceptable in
terms of their scope, testability, technology independence etc. We can
then try to propose feasible ones, hopefully get them accepted, and then
move on to identify other plausible SCs that may have been hidden in the
mega-SC. All those managing the process of getting the first Working Draft
of 2.1 seem to say that adding things in later iterations is a
possibility. I guess that maybe we just have to trust that this will
happen in practice.
I think we really need to escape the mindset where we believe that the
reason that our SCs are being rejected is simply because people don’t
understand or care about the real user needs. Although that might possibly
apply to a few people, I’m strongly convinced that the reasons are
entirely due to the mismatch between what we have proposed and how WCAG
2.0 is used today and how WCAG 2.1 will be expected to be used when it is
available. If we continue to believe that we are dealing with a hostile
(or ignorant) set of anti-COGA people we will just end up endlessly crying
on each other’s shoulders and not doing what needs to be done to get some
successes!
Sorry if this sounds very harsh – but I fear that if we don’t accept the
real situation we will get nowhere. That would not be good for cognitive
accessibility.
Best regards
Mike
From: Michael Pluke
Sent: 08 February 2017 13:05
To: 'lisa.seeman' <lisa.seeman@zoho.com>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; Jeanne
Spellman <jspellman@spellmanconsulting.com>
Subject: RE: Proposals for revision of the Plain Language SC proposals for
WCAG 2.1
Sorry, catching up on a major email backlog!
I could go with 3 in principle, but only if we heavily amend what we
request. I’m not sure that simple reading level is the answer – we can
cite several examples where it is probably not. The problem is that our
current text includes so many things that are, in my opinion, completely
untestable (except with extensive and very well designed user testing).
For example, in #30 we have “unless it will result in a loss of meaning or
clarity”, “unless they are the common form to refer to concepts for
beginners”, “When a passive voice or a tense (other than present tense) is
clearer.” and several more.
We could only begin to expect WCAG approval of some of our mega-SCs (like
#30) if they are dramatically cut back to include a very few elements that
are testable. This clearly means that meeting the SC will completely
eliminate a large problem for everyone with a cognitive or learning
disability, but it should ensure that they would have less problems.
Almost all of the existing WCAG SCs are like this. There are no single SCs
that, if met, will eliminate all the reading issues for blind users (for
example). Even the full set of SCs will not do that.
The task we have of trying to improve things for people with cognitive and
learning disabilities is infinitely more difficult than trying to address
the needs of blind users (in my opinion). I think that all that we can
realistically expect is to make some improvements in 2.1. If we are too
ambitious then we will fail to do that.
An example of what I mean is #24. The original tried to give detail as
much as possible about how to reduce the cognitive load associated with
dealing with “important information” in either textual or other media
form. I think that there is no way that this vastly ambitious SC proposal
could be edited to make it acceptable to the WCAG WG. I have made a
proposal, which the SC Manager John Rochford seems to like, to only relate
to “statements which instruct a user to make a choice or take an action”.
Whereas we could, as Jeanne proposes, specify the appropriate reading
level for such statements, I suggested just three bullets which I think
are quite testable:
have only one instruction per sentence, except when two things have
to be done simultaneously;
use sentences of no more than 15 words;
should have no more than one relative pronoun per sentence. [with a
glossary entry that lists all the relative pronouns]
I have sources to say that all three of these are known to be effective
(but I have so far failed to find the time to specify them, which I
should). Arguably sticking to these might be more effective than just
specifying a reading level for these vitally important statements. I doubt
that there is a great body of research that links the effectiveness of
instructions (as such) with reading level. However, if we had to go with
reading level I still think that it would make a positive contribution to
improving the possibility that many users with cognitive and learning
disabilities would find that they could understand instructions much
better.
Best regards
Mike
From: lisa.seeman [mailto:lisa.seeman@zoho.com]
Sent: 06 February 2017 21:34
To: Thaddeus. <inclusivethinking@gmail.com>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; Jeanne
Spellman <jspellman@spellmanconsulting.com>
Subject: Re: Proposals for revision of the Plain Language SC proposals for
WCAG 2.1
I am changing my vote to 3 as well.
The SC as it is incredibly easy to write testing tools for. there are a
few open source language processing tools that you can use to count
cluses actureltys. Testing against a word list is also something that
exists already in restricted language tools and is very easy to program.
It cant be that we need to have a worse SC and use archaic reading level
tools because WCAG are to set in their ways to accept any new technology.
All the best
Lisa Seeman
LinkedIn, Twitter
---- On Mon, 06 Feb 2017 21:55:36 +0200 Thaddeus .<
inclusivethinking@gmail.com> wrote ----
I vote 3
On Feb 6, 2017 11:08 AM, "lisa.seeman" <lisa.seeman@zoho.com> wrote:
We had issues with reading level , for example the word "mode" is a lower
reading level than "hot or cold" . the lower reading level is much harder
to understand.
The reason to go with Jeanne's proposal is because wcag _might_ find it
more testable. This would only be, in my opinion, because they have not
bothered read the whole proposal and testability section (or they do not
want new tools) Also i am not sure it is more testable in different
languages and that is essential for WCAG. Wordlists requiremnts however,
can work easily in any language and wordlists can be automatically
generated by parsing a few sites.
I agree that the "unless..." clause is only human testable but that it
very typical for wcag.
I want to suggest three options
1 - we retract our current pull requests and put these in instead
2 - we go with the current pull requests. If they fail and the comments
are hard to address then we go with Jeanne's
3 -we go with the current pull requests. we can revisit this if needed
My vote is 3, to go with the current wording and see what happens
All the best
Lisa Seeman
LinkedIn, Twitter
---- On Mon, 06 Feb 2017 20:00:24 +0200 Jeanne Spellman<
jspellman@spellmanconsulting.com> wrote ----
A group of us at The Paciello Group (TPG) have been meeting every week
in January to comment on the WCAG 2.1 proposals. Because we test WCAG
2.0 all day, every (business) day, we have a lot of experience with both
the language of WCAG and the testing of WCAG. What we decided this week
is that we want to focus our efforts toward helping COGA TF draft
success criteria that will get into WCAG 2.1 and will accomplish most of
what you want -- even if it is phrased differently.
We started with the proposals that we thought would be the least
controversial to the WCAG WG to include. I looked at the Plain Language
proposals and did my best to look at the needs identified by COGA TF,
and craft language that I thought would be acceptable to the WCAG WG and
be included in the first draft version of WCAG 2.1.
The wording is quite different, but in my opinion, addresses the needs
identified. I chose reading level, because it is internationally
standardized, and there are automated tests already available. When I
look at Technique G153: Making the text easier to read
https://www.w3.org/TR/WCAG20-TECHS/G153.html , it covers most of the
items that the COGA TF identified.
Issue 30 Proposal:
Understandable Labels: Navigation elements and form labels do not
require reading ability greater than primary education level. (A)
[link to WCAG’s definition of primary education level from UNESCO
standard]
Issue 41:
Understandable Instructions: Headings, error messages and instructions
for completing tasks do not require reading ability greater than lower
secondary education level. (AA) [link to WCAG’s definition of lower
secondary level from UNESCO standard]
Delta 3.1.5 (rewrite of existing WCAG 3.1.5)
Understandable Content: Blocks of text either: (AAA)
· have a reading level no more advanced than lower secondary
education, or
· a version is provided that does not require reading ability
more advanced than lower secondary education. [links to WCAG’s
definitions of lower secondary education and blocks of text]
Attachments
- image/jpeg attachment: 08918849.jpg
- image/jpeg attachment: 08016892.jpg
- image/gif attachment: ecblank.gif
- image/gif attachment: 08123294.gif
- image/gif attachment: graycol.gif
Received on Wednesday, 8 February 2017 20:53:38 UTC