W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2016

Re: WCAG 2.1

From: Wayne Dick <waynedick@knowbility.org>
Date: Thu, 22 Sep 2016 15:50:06 -0700
Message-ID: <CAC9gL76KZSeaDSr6BTbTZp0JRkTTJ3r61xn-jqdi-aPfbb4BYQ@mail.gmail.com>
To: Phill Jenkins <pjenkins@us.ibm.com>
Cc: Jonathan Avila <jon.avila@ssbbartgroup.com>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
I sympathize with overburdened authors. There are just many tasks where one
can make a choice of equal difficulty and one is re configurable while the
other is not. Low fruit is css images. A background image that includes
button images prevents removal of the background image to provide a simpler
visual environment. If the same image is introduced through generated
content in a content: parameter it can be resolved.  Another is this. Most
WCAG 2.0 Conformant sites that are responsive can be reconfigured to meet
the exact user needs with little structural change. You may need to change
style at run time or replace the media queries with ones that are more
suitable for low vision.

Now for the fun part. When you are at CSUN this year come to my talks and
ones by my colleagues. They should be quite interesting. We will show a new
color picker that is fully keyboard compatible. In less than 50 keystrokes
a user can pick a choice from among 16M. We'll show how users with ordinary
user skill can pick the style profile they need and write it as a CSS file
or a JSON file for use with a UA or plugin. We're also hoping to show how
to make linear presentations of some important page types.. That is some
page profiles that may be used to support a more AI approach.

At CSU Long Beach we're trying to finish Vicki Hanson's work.


On Thu, Sep 22, 2016 at 2:06 PM, Phill Jenkins <pjenkins@us.ibm.com> wrote:

> Jonathan,
> I wasn't responding only to you, so hopefully no offense was taken.
> And thanks for your reply, you clearly got my point.  Because we used
> sentences instead of just terms, it was clear to me and you that we (you
> and I) were not intending to say a criterion was not important to some
> users.
> So, it may not be a term that I'm recommending to change, but perhaps,
> requiring everyone (not just you and me) to use more full sentences with
> the terms we choose to use.
> Levels?
> Levels of what?
> What are the levels of the success criteria?
> Are they levels of importance to end users?
> No, not at all as we have both observed, acknowledged, and I think agreed
> to.
> But, we also agree that Level A criterion are most important to the web
> developer.
> Are they levels of severity to end users?
> no not at all. . .
> Are they levels of priority?
> hmm, to whom?  Yes they are levels of priority to web developers!
> but not levels of important to end users.
> Perhaps we just need to add the "to whom" in the sentence, instead of just
> using the term "Levels".
> The working group needs to ask itself: "Why is the level changing from A
> to AA?" I hope because it is changing the priority to the web developer
> (not to the end user) BECAUSE the criterion is no longer critical
> because now (but there wasn't a decade ago back in 2003) there is a way, a
> common ubiquitous way for the browser and AT to make the content accessible.
> In other words some or all of the complex considerations the working group
> dealt with back in 2003 are no longer valid.
> I believe this is exactly how the 2X criterion (*1.4.4*
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-scale>*Resize
> text* ) got set (not lowered) from level A to Level AA because more of
> the problem was solved by then by the browsers including a zoom feature.
> When we did WCAG 1.0, the browsers didn't have that feature. Should the
> criterion be changed to 4X because of the aging population?
> So I'm trying to change the notion that the levels are about levels of
> importance or severity to the end users, but, that they are levels of
> importance to the web developer.
> In my opinion, I think we may have made a mistake by changing the term
> from Priority to Level, but in either case, the "to whom" was the part that
> really caused the confusion
> and group's issues.
> With this line of thinking we don't have to get rigid on statements like:
> no Level A criterion can be lowered to level AA.
> or
> its got to be changed to level A from level AA because its so important to
> this set of users.
> Don't get me wrong, level of importance and severity to end users is of
> critical importance and critical input to setting the level (or priority),
> but the working groups has to consider the level of priority to the web
> developer (all zillion of them) verses the level of priority to the AT and
> browser companies (all ~100 of them).
> Another example:
> Content simplification and content summarization is of critical importance
> to some (even more) users.  Its actually a federal law that some US federal
> government content has to be "easy to read", however testable that is or
> isn't.
> When is it *simple enough*? and to whom is it simple enough, and what is
> it that has to be simple enough?
> There are at least three (3) parts to that equation that the intent of the
> law was trying to solve.
>         Is simple enough defined as 5th grade, 8th grade, or other
> considerations?
>         Is to whom all public, or all students at a university, or some
> other know group?
>         Is what is include? legal agreements, university textbooks, voting
> guides, or some other know list?
>                 ADA seemed to only apply to brick & mortar places, so lets
> not repeat that mistake.
> Where does cognitive assistive technology play a role vs placing all the
> responsibility of the web developer/content author?
> Where does narrowing the applicable content play a role?  Lawyers rarely
> regulate themselves by the way. . .
>         Do those complex consideration yield a different level of priority
> to the web developer?
> So, I do ask my self and the WCAG 2.1 working group, does UAAG need to be
> updated in parallel?
> ___________
> Regards,
> Phill Jenkins,
> Senior Engineer & Business Development Executive
> IBM Research - IBM Accessibility
> ibm.com/able <http://www.ibm.com/able>
> facebook.com/IBMAccessibility <http://www.facebook.com/IBMAccessibility>
> twitter.com/IBMAccess
> ageandability.com
> From:        Jonathan Avila <jon.avila@ssbbartgroup.com>
> To:        "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
> Date:        09/21/2016 06:28 PM
> Subject:        RE: WCAG 2.1
> ------------------------------
> Phil, I had no intention of saying that some criteria were not important
> to some users.  I agree they are all not just usability issues. They are
> barriers to users with disabilities.  But as you acknowledge some are items
> that must be solved by the author while others can be solved through the
> browser or AT.  The Understanding Conformance document indicates that
> levels are set based on whether the Success Criterion is *essential* (in
> other words, if the Success Criterion isn't met, then even assistive
> technology can't make content accessible).  So to that degree they carry a
> greater weight.
> So when I used the term important I was thinking more along these lines –
> some SC are essential because they can’t be worked around by AT and thus
> having the author address these is of greater need.  The term severity or
> priority would probably also be objectionable.  But knowing which criteria
> affect multiple user groups and which ones can’t be worked around are real
> world needs that organizations must consider when there is a limited time
> to fix issues.    Most organizations do have to prioritize issues whether
> something is a barrier versus something AT can overcome is a realistic
> factor in helping them make these decisions.    While using the term change
> level would be best—it carries an ambiguity  – but in the email I was
> responding to it appeared that there was confusion about what level was the
> minimum level of accessibility.  Also many organizations are confused when
> we speak of Level AA conformance and automatically assume incorrectly that
> excludes level A conformance.  So we do need to find a term that is
> appropriate and understandable to communicate.  What term would you
> recommend?
> Jonathan
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> *jon.avila@ssbbartgroup.com* <jon.avila@ssbbartgroup.com>
> 703.637.8957 (Office)
> Visit us online: *Website* <http://www.ssbbartgroup.com/>| *Twitter*
> <https://twitter.com/SSBBARTGroup>| *Facebook*
> <https://www.facebook.com/ssbbartgroup>| *Linkedin*
> <https://www.linkedin.com/company/355266?trk=tyah>| *Blog*
> <http://www.ssbbartgroup.com/blog/>
> *Check out our Digital Accessibility Webinars!*
> <http://www.ssbbartgroup.com/webinars/>
> *From:* Phill Jenkins [mailto:pjenkins@us.ibm.com <pjenkins@us.ibm.com>]
> *Sent:* Wednesday, September 21, 2016 1:34 PM
> *To:* w3c-wai-ig@w3.org
> *Subject:* RE: WCAG 2.1
> I do not support of the use of phrases such as "raising" or "lowering
> importance" or making a success criterion "more" or "less important".
> There is a misunderstanding out there about the levels (or its just a
> misunderstanding in using English to describe things or me in understanding
> things).  Saying that it is important today or more important tomorrow to
> conform with the success criteria is a very different concept in my mind
> that saying that level A success criterion is more important to this end
> user than a level triple A success criterion is to that other user.
> Remember that it is the web content accessibility guidelines WCAG , not the
> end user experience guidelines.  In my opinion all the success criterion
> are important, period.  Level A and double A and triple A are *not* about
> importance, they are about *if and when* they apply to the web content
> (vs the browser or AT) and to whom do they benefit.  One of the questions
> that the working group asked themselves when assigning a level to the
> success criterion was the following: Does it apply:
>        to all the content all the time?
>        to all web sites all the time?
>        for all audiences all the time?
> Another questions that was asked was about whether it is best solved by
> the user agent (browser and/or AT) or whether it is best solved by or in
> the web content by the web designer and developers. You can read a wide
> range of interacting issues that the working group consider in *Understanding
> Levels of Conformance*
> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head>
> .
> Conformance with triple AAA is not better or more accessibility, it is
> more responsibility on the author more of the time because its more
> applicability.  The notion of "higher levels" (not higher importance) of
> conformance comes from that concept that meeting triple AAA requires
> passing more, all 65 success criteria, while double AA conformance means
> passing fewer only 38 success criteria. Level A is the lowest level,
> meaning it only requires meeting 25 success criteria.  Even the normative
> WCAG standards says:
> "*Conformance  *This section is *normative*
> <https://www.w3.org/TR/WCAG20/#normativedef>. . . . *Note 2: *It is not
> recommended that Level AAA conformance be required as a general policy for
> entire sites because it is not possible to satisfy all Level AAA Success
> Criteria for some content."
> Also, because of conflicts I never recommend requiring many of the Level
> AAA success criterion all the time on all web content for all users.  Here
> are 3 examples:
> 1.        Conforming to *1.4.6*
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast7>*Contrast
> (Enhanced) Level AAA* creates a very high contrast site that is
> distracting and "striking" for some (many?) users.  "The contrast ratio
> of 7:1 was chosen for level AAA because it compensated for the loss in
> contrast sensitivity [by some]...users... People with more than [20/80
> vision] usually use assistive technologies to access their content (and the
> assistive technologies usually have contrast enhancing, as well as
> magnification capability built into them). The 7:1 level therefore
> generally provides compensation for [some users] who do not [have their]
> assistive technology. . . ". Therefore, in my opinion, requiring 7:1
> contrast level all the time on all content is akin to requiring a one size
> fits all contrast setting that is not in harmony with the principles of web
> accessibility and a one size fits one through transformation technologies
> in the browsers and AT, not provided by the web site owner.
> 2.        Conforming to *1.4.9*
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-text-images>*Images
> of Text (No Exception) Level AAA:*  would also require no logos, no
> images of text, no exceptions.  I'm sure SVG is making progress and being
> adopted in many places, but I do not think we are at a point yet that we
> can require 1.4.9 on all web sites all the time, hence that is at least one
> reason it is level AAA. From a cognitive disability perspective, logos help
> with branding recognition of which website the user is on.  I would never
> recommend an "East Berlin" look (if you ever visited East Berlin before the
> wall came down you would know what I mean) for all websites.  However, it
> could make sense to require this level AAA criterion in some limited cases,
> for a controlled set of users, such as a set of AT training pages, hence
> its level AAA.  But I do not believe sighted users with some cognitive
> disabilities or aging users  would ever benefit.  Most of us are thinking,
> isn't that the role of the assistive technology, screen readers, etc, for
> most web sites and the answer is of course, hence level AAA.
> 3.        Conforming to *2.4.10*
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-headings>*Section
> Headings* Level AAA:  would require section headings, "This provision is
> included at Level AAA because it cannot be applied to all types of content
> and it may not always be possible to insert headings. For example, when
> posting a pre-existing document to the Web, headings that an author did not
> include in the original document cannot be inserted. Or, a long letter
> would often cover different topics, but putting headings into a letter
> would change the letter. However, if a document can be broken up into
> sections with headings, it facilitates both understanding and navigation".
>  So you see, in my opinion, section headings are very important to some
> users for better comprehension, easier understanding, etc.  Its level AAA
> in my opinion also because of the difficulty of applying it all the time by
> the web owner.  New simplification and summarization technology is
> emerging, but we would not want to necessarily change the original content
> all the time in all cases - hence it would remain a level AAA.
> So, moving a success criteria from level A to double A is not necessarily
> increasing the importance or benefit to all end users any more than moving
> it from level AA to single A is not lowering the importance or benefit to
> all end users.   However, moving a success criteria from double AA to
> single A (or adding a success criteria to level A) *is* about increasing
> the amount of responsibility and work onto the web content owner and
> increasing its applicability by requiring the criterion to be applied to
> all (or more) content, for all (or more) web sites and to all (or more)
> audiences all (or more) of the time.  Remember that it is the web content
> accessibility guidelines WCAG , not the end user experience guidelines.
> WCAG conformance is about whether the web content conforms to the standard
> by passing the testable success criteria.  Browsers, AT, and end users
> settings are all still part of the equation.  There are also
> standards for the browser, called the User Agent Accessibility Guidelines
> UAAG, that  browsers should conform to.  See the discussion on essential
> components for more background.
> Please, lets stop the misunderstanding that WCAG conformance is the end
> all and that the levels are about importance.
> Essential Components of Web Accessibility:
> *https://www.w3.org/WAI/intro/components.php*
> <https://www.w3.org/WAI/intro/components.php>
> WCAG 2.0: Conformance Requirements
> *https://www.w3.org/TR/WCAG20/#conformance-reqs*
> <https://www.w3.org/TR/WCAG20/#conformance-reqs>
> Understanding WCAG: Understanding Levels of Conformance
> *https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head*
> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head>
> ___________
> Regards,
> Phill Jenkins,
> IBM Research - IBM Accessibility
> *ibm.com/able* <http://www.ibm.com/able>
> *facebook.com/IBMAccessibility* <http://www.facebook.com/IBMAccessibility>
> *twitter.com/IBMAccess* <http://twitter.com/IBMAccess>
> ageandability.com
> From:        Jonathan Avila <*jon.avila@ssbbartgroup.com*
> <jon.avila@ssbbartgroup.com>>
> To:        "*w3c-wai-ig@w3.org* <w3c-wai-ig@w3.org>" <*w3c-wai-ig@w3.org*
> <w3c-wai-ig@w3.org>>
> Date:        09/21/2016 08:21 AM
> Subject:        RE: WCAG 2.0
> ------------------------------
> Ø  So you mean in WCAG2.1 some provisions will be raised from  AA to AAA
>   or   A to AA?
> It is my personal understanding that the importance of success criteria in
> WCAG 2.1 cannot be made less important.  So an A would not go to AA.  WCAG
> 2.1 by its definition must ensure that if something passes WCAG 2.1 at a
> given level it would also pass WCAG 2 at the same level.
> What is a possibility is that a success criteria might get more important.
>  So a level WCAG 2 AAA criteria might become WCAG 2.1 AA or a WCAG 2 level
> AA might become WCAG 2.1 level A.
> Jonathan
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> *jon.avila@ssbbartgroup.com* <jon.avila@ssbbartgroup.com>
> 703.637.8957 (Office)
> Visit us online: *Website* <http://www.ssbbartgroup.com/>| *Twitter*
> <https://twitter.com/SSBBARTGroup>| *Facebook*
> <https://www.facebook.com/ssbbartgroup>| *Linkedin*
> <https://www.linkedin.com/company/355266?trk=tyah>| *Blog*
> <http://www.ssbbartgroup.com/blog/>
> *Check out our Digital Accessibility Webinars!*
> <http://www.ssbbartgroup.com/webinars/>
> *From:* Balusani, Shirisha [*mailto:sirib@uillinois.edu*
> <sirib@uillinois.edu>]
> *Sent:* Wednesday, September 21, 2016 8:58 AM
> *To:* Gregg Vanderheiden; *w3c-wai-ig@w3.org* <w3c-wai-ig@w3.org>
> *Subject:* RE: WCAG 2.0
> ·       *Level A: *For Level A conformance (the minimum level of
> conformance), the *Web page*
> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#webpagedef>
> *satisfies*
> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#satisfiesdef>all
> the Level A Success Criteria, or a *conforming alternate version*
> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#conforming-alternate-versiondef>
> is provided.
> ·       *Level AA: *For Level AA conformance, the Web page satisfies all
> the Level A and Level AA Success Criteria, or a Level AA conforming
> alternate version is provided.
> ·       *Level AAA: *For Level AAA conformance, the Web page satisfies
> all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA
> conforming alternate version is provided.
> So you mean in WCAG2.1 some provisions will be raised from  AA to AAA   or
>   A to AA?
> Thanks,
> Siri
> *From:* Gregg Vanderheiden [*mailto:gregg@raisingthefloor.org*
> <gregg@raisingthefloor.org>]
> *Sent:* Tuesday, September 20, 2016 11:54 PM
> *To:* Balusani, Shirisha <*sirib@uillinois.edu* <sirib@uillinois.edu>>
> *Subject:* Re: WCAG 2.0
> You cannot change a normative part of a standard after it has been issued.
> There has been some discussion of a new  WCAG 2.1 — and some discussion in
> that about raising some of the provisions from AA to A   or AAA to AA
> but going from AA to AAA would be lowering an SC’s level
> *gregg*
> On Sep 20, 2016, at 10:59 PM, Balusani, Shirisha <*sirib@uillinois.edu*
> <sirib@uillinois.edu>> wrote:
> Hi All,
> I’m curious to know if the WCAG 2.0's  success level criteria  will be
> raised from AA to AAA in near future .
> Thanks
> Siri
Received on Thursday, 22 September 2016 22:50:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 22 September 2016 22:50:40 UTC