Re: Alternative approach for Plain Language

Hi Mike,

> That is the point of techniques; they offer ways of achieving a target
but not the only ways.

You do realize you are explaining this to one of the WCAG 2.0 Editors who
helped establish that mechanism in WCAG 2.0, right?

> Well, that really depends on what guidance goes into the Understanding
Document, how the techniques are written, and how organizations/teams adopt
the SC.

I'm sorry, that isn't 100% correct. The Understanding and Techniques
documents, while hugely useful in helping explain not only what the needs
are, but also offering suggested ways in addressing those needs, are by
design and construction *non-normative* - the only normative requirements
we have is the actual WCAG 2.0.

I can understand and promote a position that suggests that the *real* goal
of WCAG is to support and include persons with disabilities (it's why we're
all here), but we need to also remember that, like-it-or-not, we're also
talking about "legal compliance" in the mix, which is why the testability
of the SC is so important.

Gregg is indeed right; he could post complex and convoluted language to
describe the topic or purpose, and while the functional outcome would
likely not meet our understanding of the needs of all users, he would
*technically* be in compliance. That may feel counter to our desires, but
that's the hand we've been dealt - if we wanted our Recommendation to have
the force of law (or more accurately be adopted by legislations around the
planet), we had to accept the constraints that subsequently placed on it's
construction.

> I frequently fail poor language in labels and headings using this SC.

As is both your right and interpretation, but the actual fact of the matter
is you are also applying your judgement and perspective here (not wrong,
but it does add an additional layer of complication).

Here at Deque, we have a significantly large number of testing evaluators,
coupled with the need to ensure that our evaluation reports for our clients
are consistent, accurate and as devoid of personal opinion as possible.
(The old joke about putting 5 accessibility experts in a room, posing a
question, and getting 7 correct answers isn't really a joke, but a reality
we live with daily). The Understanding and Techniques documents certainly
help us define a standard interpretation methodology, but at the end of the
day we are obliged to report truthfully what is a mandated SC requirement,
and what is "Best Practice", and we work hard to ensure that bright line is
preserved.

> the ARIA techniques clearly encouraged adoption and offered guidance to
teams on how to use it to better content.

​That may be true at IBM, and perhaps even other large organizations, but
it isn't a truism everywhere. IBM was an early adopter of ARIA for a
multitude of reasons, but I previously worked at a bank that was the
opposite, and as little as 3.5 years ago ARIA *was not* a viable solution
to address many situations we encountered, and in fact we often had to rely
on one or more of the *other* techniques to meet our compliance needs (for
example, off-screen text rather than using aria-label="").​

This was completely related to which browsers we had to support in those
days, including browsers that lacked full ARIA support - the point being
that the ARIA techniques alone did not accelerate adoption, they were but
one piece of a much larger puzzle. At that time (and where *I* worked)
Market forces were a significantly larger factor in the ARIA adoption
decision.

Mike, I've gone back and re-read your proposal, and while I think I
understand what you are suggesting (and generally agree with the direction
you are headed), I didn't see any actual proposed language for a testable
Success Criteria. Perhaps you could suggest an initial draft wording for us
to review?

Cheers!

JF


On Wed, May 24, 2017 at 8:07 AM, Michael Gower <michael.gower@ca.ibm.com>
wrote:

> >  Am I missing something?
>
> Yes, I think you need to go back and reread it a bit more carefully.
>
> > You say it plugs a hole regarding labels
>
> Nope, I never say that. This is entirely concerned with instructions.
>
> > The techniques could indeed be attached to the SC — but none are
> required to meet the SC.
>
> That is the point of techniques; they offer ways of achieving a target but
> not the only ways. However, techniques offer paths and encourage adoption.
> Use of ARIA doesn't exist as an SC. But the ARIA techniques clearly
> encouraged adoption and offered guidance to teams on how to use it to
> better content.
>
> >  I could use very complicated language to describe the topic or purpose
> and I would still pass.   The instructions themselves can also be
> complicated and pass this SC.
>
> Well, that really depends on what guidance goes into the Understanding
> Document, how the techniques are written, and how organizations/teams adopt
> the SC. If you look at the Understanding document and general techniques
> for 2.4.6, you'll see that there is in fact a lot of context and guidance
> offered there that is not normative but is compelling to authors to improve
> content. I frequently fail poor language in labels and headings using this
> SC.
>
> So for an SC directed at improving the clarity and understandability of
> Instructions, imagine if you had techniques that were gathered under
> General topics like:
>
>    - Using simple, clear and common words
>    - Using present tense and active voice
>
> etc
>
> I understand the limitations of the approach. But I also understand what
> could be achieved by getting the techniques in front of people.
>
> Michael Gower
> IBM Accessibility
> Research
>
> 1803 Douglas Street, Victoria, BC  V8T 5C3
> gowerm@ca.ibm.com
> voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034
>
>
>
> From:        Gregg C Vanderheiden <greggvan@umd.edu>
> To:        Michael Gower <michael.gower@ca.ibm.com>
> Cc:        w3c-wai-gl@w3.org
> Date:        2017-05-23 07:08 PM
> Subject:        Re: Alternative approach for Plain Language
> ------------------------------
>
>
>
> I’m not sure I understand.
> l followed the link but am very confused by what I land on.
>
>
> Is the SC =  "Instructions describe the topic or purpose."
>
> If so - I can’t see how any instructions could fail.   I guess you could
> have instructions that tell you what to do - but do not tell you what
> carrying out the instructions will accomplish.
>
> The techniques could indeed be attached to the SC — but none are required
> to meet the SC.  I could use very complicated language to describe the
> topic or purpose and I would still pass.   The instructions themselves can
> also be complicated and pass this SC.
>
>
> Am I missing something?
>
>
> You say it plugs a hole regarding labels — but this doesn’t talk about
> labels at all.      ????
>
>
> If you just want a place to hang techniques  this works — but only
> techniques dealing with instructions — not labels (unless you really
> stretch it)
>
>
> confused in maryland,
>
> apologies if I am misunderstanding this
>
>
> *g*
>
>
>
> Gregg C Vanderheiden
> *greggvan@umd.edu* <greggvan@umd.edu>
>
>
>
>
> On May 23, 2017, at 2:34 PM, Michael Gower <*michael.gower@ca.ibm.com*
> <michael.gower@ca.ibm.com>> wrote:
>
> On today's call (in the extended time), I proposed a departure from the
> current approach to Plain Lanugage, which I was asked to draft. Here it is:
>
> *https://github.com/w3c/wcag21/issues/30#issuecomment-303492002*
> <https://github.com/w3c/wcag21/issues/30#issuecomment-303492002>
>
> Michael Gower
> IBM Accessibility
> Research
>
> 1803 Douglas Street, Victoria, BC V8T 5C3
> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
> voice: (250) 220-1146 * cel: (250) 661-0098 * fax: (250) 220-8034
>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion