- From: Jeanne Spellman <jspellman@spellmanconsulting.com>
- Date: Tue, 10 Mar 2020 18:08:52 -0400
- To: Charles Adams <charles.adams@oracle.com>, John Foliot <john.foliot@deque.com>
- Cc: Silver TF <public-silver@w3.org>
- Message-ID: <39074851-745c-5414-06b0-48954d0a2865@spellmanconsulting.com>
Actually, Alastair did not propose a testable statement. We know from the Silver research that testable statements are very difficult for people to understand. Great for computers, but not so good for people. I would be opposed to normative testable statements. Alastair proposed a functional outcome, which is easier to understand. I want to make things easier for the testing companies wherever possible, but not at the expense of being able to include nuanced guidelines that COGA and LV need. I don't want to make Silver into WCAG 2.3. There is a place for testable statements in the informative tests, because the testable statements make sense when they are technology specific, Process-lightweight, and easily updated for evolving technology and disability needs. jeanne On 3/10/2020 3:54 PM, Charles Adams wrote: > > JF, what do you think of Alastair's proposal? If I understand it, the > proposal consists of providing a plain language explanation followed > immediately by a testable statement. > > Chuck > > On 3/10/2020 7:47 AM, John Foliot wrote: >> Hi Jeanne, >> >> All of the plain language examples we've seen to date lack enough >> specificity to be a normative requirement IMHO. >> >> Take Clear Language. >> The current "Requirement" states: /Use clear language to make it >> easier for readers to understand. / >> >> Without a clear metric to measure that however, it is a meaningless >> ask, as nobody will be able to effectively evaluate whether or not >> the goal has been met: I can claim it's clear and easy to understand, >> you can claim it's not, and then what? >> >> (I'll note that the current draft example >> <https://urldefense.com/v3/__https://docs.google.com/document/d/1LfzTd_8WgTi0IUOOjUCRfRQ7e7__FRcnZow4w7zLlkY/edit*__;Iw!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPntIsVTVrw$> >> has, as a "requirement" the following: "Remove unnecessary words" - >> my question is, unnecessary to whom? The end-user with a University >> degree reading level vocabulary, or the end-user with a Grade 6 >> reading level vocabulary? Would this be "better": "Use clear language >> - make easier understand" - there, I removed "unnecessary" words... >> Additionally, that very much feels like an "English" language >> requirement, but does that apply to all languages? Spanish is >> significantly more 'compact' than English, with different grammar >> rules - "rules" that already remove superfluous words, so I will >> argue against that measurement rule as being too English-centric) >> In the context of the W3C being a place where we create STANDARDS, I >> will suggest that the "normative" parts are the measurable >> standardized parts, everything else is backgrounder and explanation >> and non-normative. Merriam Webster backs me up: >> >> ***Normative >> <https://urldefense.com/v3/__https://www.merriam-webster.com/dictionary/normative__;!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPnt1OmocZA$>*: >> of, relating to, or determining norms or _standards_ >> >> *Standard* >> <https://urldefense.com/v3/__https://www.merriam-webster.com/dictionary/standard__;!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPnvUcIp21w$>: >> something set up and established by authority as _a rule for the >> measure of quantity, weight, extent, value, or quality_ >> >> I fully appreciate that today there remains a fair bit of >> subjectivity to our evaluation process (what, exactly, is appropriate >> alt text?), but it seems to me we should be trying to squeeze out the >> subjectivity, not add to it. A vaguely worded, hard-to-measure >> "normative" requirement is, frankly, an oxymoron IMHO. >> >> >> JF >> >> On Mon, Mar 9, 2020 at 5:48 PM Jeanne Spellman >> <jspellman@spellmanconsulting.com >> <mailto:jspellman@spellmanconsulting.com>> wrote: >> >> It could also be the guideline itself. It's clear and it >> wouldn't take much to make it plain language. >> >> >> On 3/9/2020 6:10 PM, Alastair Campbell wrote: >>> >>> Hi everyone, >>> >>> It was an interesting conversation on the normative/informative >>> aspects in silver / WCAG 3, I just wanted to provide an example >>> for consideration. >>> >>> We have a sliding scale of granularity, from least granular to >>> most granular: >>> >>> * WCAG 2.x Principle (a categorisation tag) >>> * WCAG 2.x guideline >>> * Silver guideline >>> * WCAG 2.x Success criteria >>> * *(Current informative line)* >>> * Silver Getting started / WCAG 2.x Understanding >>> * Silver methods >>> * WCAG 2.x Techniques >>> >>> My main points were that: >>> >>> * ‘normative requirement’ does not need to equal ‘testable >>> statement’, they can be different things. >>> * The more content that is normative, the more that has to go >>> through a more complex process. >>> >>> So my suggestion was to add something concise between the >>> guideline and method level. >>> >>> Taking a concrete example, e.g. Visual contrast of text >>> <https://urldefense.com/v3/__https://raw.githack.com/w3c/silver/ED-draft=comments-changes-js/guidelines/index.html*visual-contrast-of-text__;Iw!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPnvFu7TEKQ$>, >>> the ‘normative’ bits could be something like: >>> >>> *2.3 Visual Contrast of Text* >>> >>> Provide sufficient contrast between foreground text and its >>> background. >>> >>> Text meets the _Advanced Perceptual Contrast Algorithm_ unless >>> it is _incidental_. >>> >>> The last line could be behind a show/hide, or styled >>> differently, or be in the top line of Getting started. The links >>> would go to the evaluation tab and a definition of incidental. >>> It could also be much longer if that was easier to understand. >>> >>> Or for clear language: >>> >>> *2.2 Clear Language* >>> >>> Use clear language to make it easier for readers to understand. >>> >>> Ensure that text content follows the _principles for plain >>> language_ by editing it to match, following a style guide, or >>> testing and updating it. >>> >>> I hashed that together from the “How” and the method information. >>> >>> To address another issue around the complexity of language: If >>> the normative language is not constrained by being a very >>> concise testable statement it could be longer and easier to >>> understand. Adjusting some of the ‘how to’ material could also >>> be the solution, and marking that as normative. >>> >>> Another aspect is that some ‘normative requirements’ could be >>> process based, e.g. When creating or updating navigation a >>> user-centred design approach is included. That might be a >>> silver/gold (or whatever the terms are) criteria compared to >>> WCAG 2.x, but I don’t see that as a problem for ‘normative >>> requirements’. >>> >>> Cheers, >>> >>> -Alastair >>> >> >> >> -- >> *John Foliot* | Principal Accessibility Strategist | W3C AC >> Representative >> Deque Systems - Accessibility for Good >> deque.com >> <https://urldefense.com/v3/__http://deque.com/__;!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPnvC7-wNoQ$> >> >>
Received on Tuesday, 10 March 2020 22:09:05 UTC