- From: Jeanne Spellman <jspellman@spellmanconsulting.com>
- Date: Wed, 8 Feb 2017 16:59:19 -0500
- To: "lisa.seeman" <lisa.seeman@zoho.com>, Michael Pluke <Mike.Pluke@castle-consult.com>
- Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
- Message-ID: <a6c6d160-9f07-eebd-61e8-adadcf803c4b@spellmanconsulting.com>
I agree that if you can get AGWG to accept the 3 Plain Text SCs as is,
by all means, go for it.
We didn't have a detailed discussion on the rationale of "reading level"
in the meeting. One of the reasons I chose reading level, is that there
is an existing WCAG Technique that I thought matched most of what you
were looking for in Plain Text, and could be tweaked to add more. IMO,
it would be easier to adjust the Technique to get what you want. This
Technique could be applied to each of the 3 Plain Text SCs.
Note that it does include using shorter, more common terms, which I
think was the biggest objection to using reading level.
G153 - https://www.w3.org/TR/WCAG20-TECHS/G153.html
Here is an excerpt of what G153 includes:
*
Develop a single topic or subtopic per paragraph.
*
Use the simplest sentence forms consistent with the purpose of the
content. For example, the simplest sentence-form for English
consists of Subject-Verb-Object, as in John hit the ball or The Web
site conforms to WCAG 2.0.
*
Use sentences that are no longer than the typical accepted length
for secondary education. (Note: In English that is 25 words.)
*
Consider dividing longer sentences into two.
*
Use sentences that contain no more than two conjunction.
*
Indicate logical relationships between phrases, sentences,
paragraphs, or sections of the text.
*
Avoid professional jargon, slang, and other terms with a specialized
meaning that may not be clear to people.
*
Replace long or unfamiliar words with shorter, more common terms.
*
Remove redundant words, that is, words that do not change the
meaning of the sentence.
*
Use single nouns or short noun-phrases.
*
Remove complex words or phrases that could be replaced with more
commonly used words without changing the meaning of the sentence.
*
Use bulleted or numbered lists instead of paragraphs that contain
long series of words or phrases separated by commas.
*
Make clear pronoun references and references to other points in the
document.
*
Use the active voice for documents written in English and some other
Western languages, unless there is a specific reason for using
passive constructions. Sentences in the active voice are often
shorter and easier to understand than those in the passive voice.
*
Use verb tenses consistently.
*
Use names and labels consistently.
-------
Also, on testing: Manual testing is more complex than just a simple 8 of
10. One of the issues that AGWG has to look at is the burden of
testing. For most success criteria, this 8 of 10 is ok. But for the
Plain Language SCs, this is putting a large new burden on testing
companies. They would need to hire editors. Accessibility testers are
mostly not qualified to do language editing -- some are, of course. It
adds a lot to the site testing, because the testers would have to read
all the text for find the plain text errors, instead of just checking
small amounts of text.
I think there will be a lot of push-back on the Plain Language SCs as
currently proposed.
On 2/8/2017 4:28 PM, lisa.seeman wrote:
> Hi Mike
> I think we basically agree, if we can get something more testable then
> we should, and cut or reduce the scope to get things though. However
> we also that reading age algorithm does not address the issue. There
> is a difference between cutting /rewording / getting part of what we
> want and going for a solution that might causes as many problems as it
> solves.
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Wed, 08 Feb 2017 18:59:20 +0200 *Michael
> Pluke<Mike.Pluke@castle-consult.com>* wrote ----
>
> 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 <https://aka.ms/o0ukef>
>
> _____________________________
> From: lisa.seeman <lisa.seeman@zoho.com <mailto: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
> <mailto:mike.pluke@castle-consult.com>>
> Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org
> <mailto:public-cognitive-a11y-tf@w3.org>>, Jeanne Spellman
> <jspellman@spellmanconsulting.com
> <mailto: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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Wed, 08 Feb 2017 15:42:12 +0200 *Michael Pluke
> <Mike.Pluke@castle-consult.com
> <mailto: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
> <https://github.com/w3c/wcag21/issues/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
> <mailto:lisa.seeman@zoho.com>>
> *Cc:* public-cognitive-a11y-tf
> <public-cognitive-a11y-tf@w3.org
> <mailto:public-cognitive-a11y-tf@w3.org>>; Jeanne Spellman
> <jspellman@spellmanconsulting.com
> <mailto: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 <https://github.com/w3c/wcag21/issues/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
> <https://github.com/w3c/wcag21/issues/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
> <mailto:inclusivethinking@gmail.com>>
> *Cc:* public-cognitive-a11y-tf
> <public-cognitive-a11y-tf@w3.org
> <mailto:public-cognitive-a11y-tf@w3.org>>; Jeanne Spellman
> <jspellman@spellmanconsulting.com
> <mailto: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<http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
> ---- On Mon, 06 Feb 2017 21:55:36 +0200 *Thaddeus
> .<<mailto:inclusivethinking@gmail.com>inclusivethinking@gmail.com
> <mailto:inclusivethinking@gmail.com>**>* wrote ----
>
> I vote 3
>
> On Feb 6, 2017 11:08 AM, "lisa.seeman"
> <lisa.seeman@zoho.com <mailto: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<http://il.linkedin.com/in/lisaseeman/>,
> Twitter <https://twitter.com/SeemanLisa>
>
>
> ---- On Mon, 06 Feb 2017 20:00:24 +0200 *Jeanne
> Spellman<jspellman@spellmanconsulting.com
> <mailto: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]
>
>
>
>
>
Received on Wednesday, 8 February 2017 22:00:01 UTC