RE: Supplementary document for WCAG 2.1

Dear List,

I would like to point out that regaurdless of individual opinion, using all
caps and bolded text to communicate is typically considered unprofessional.
More specific to the group, it is very difficult for people with some
disabilities to infer tone and this can be very confusing or distressing to
some readers. I have recently attempted to unsubscribe from this list for
these types of reasons but could not do so using the approach outlined on
the homepage. Would some please outline the best way to unsubscribe?

Best,
Thaddeus

On May 26, 2017 7:51 AM, "White, Jason J" <jjwhite@ets.org> wrote:

> I agree with Gregg’s description of the problem, recalling the long,
> detailed and extensive discussions that took place when we were attempting
> to improve support for the needs of people with learning, language and
> cognitive disabilities in WCAG 2.0.
>
>
>
> Writing good success criteria is genuinely difficult, and not everything
> which it is important and useful to do is also amenable to becoming a WCAG
> requirement.
>
>
>
> *From:* Gregg C Vanderheiden [mailto:greggvan@umd.edu]
> *Sent:* Friday, May 26, 2017 10:29 AM
> *To:* Milliken, Neil <neil.milliken@atos.net>
> *Cc:* David MacDonald <david100@sympatico.ca>; Alastair Campbell <
> acampbell@nomensa.com>; public-cognitive-a11y-tf <
> public-cognitive-a11y-tf@w3.org>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>
> *Subject:* Re: Supplementary document for WCAG 2.1
>
>
>
> Neil we all know that it would be better if everything worked for everyone
> out of the box.  but it simply is not possible to do.   and for may
> disabilities what is good for one is not good for another.  even within
> cognitive, language, and learning disabilities  this is true.    and making
> something that is infinitely flexible makes it infinitely complicated to
> configure.
>
>
>
> we are working on making auto-personalization easy to lessen this last
> effect but it is still not solved.
>
>
>
> Using AT can be something that is automatic to the user.   Once it is
> there it is just part of the user agent you are using to view things.    So
> it is always there and the normal way to do them.
>
>
>
> Like wearing glasses instead of having everything in larger print.   Even
> though wearing glasses is a pain.
>
>
>
>
>
> the problem we have is that we have precious little good AT for
> cognitive.  Or to say it more accurately, we have good AT for precious
> little types and degrees of cognitive, language, and learning disabilities.
>
>
>
> But if we made all pages directly accessible by people who are blind -  it
> would not work well.   And screen readers by the way are a real pain.   and
> many people who are blind find them very hard or impossible to use.
>
>
>
> So David was not saying ‘don’t put access for cognitive, language, and
> learning disabilities in WCAG  (he has long been a proponent — as have I by
> the way).   It is just that it is REALLY hard to find things what can
> qualify  - as people now find — and that there is SO MUCH more that needs
> to be done than can be handled by saying “every page must do this”
>
>
>
> This is true for all disabilities by the way — but even more so for
> cognitive, language, and learning disabilities than any other.
>
>
>
> There is LOT of provisions for cognitive, language, and learning
> disabilities  in WCAG 2.0.     That is not the problem.   the problem is
> that what is there only addresses part of the problem for some of the
> users.   there is *SO MUCH MORE NEEDED*.
>
>
>
> unfortunately there is and always will be *MUCH MORE NEEDED* than *EVER
> CAN BE REDUCED TO TESTABLE REQUIREMENTS*  that would *BE GENERALLY
> APPLICABLE*  to all websites.
>
>
>
> And unless both of those (and the other SC requirements are met  we cannot
> *REQUIRE* that they be done *ON ALL WEBSITES*.
>
>
>
>    - we *CAN* create a document with SC that are *NOT TESTABLE* — but
>    then it can *NEVER BE REQUIRED*
>    - we *CAN* create a document with SC that are *NOT APPLICABLE
>    EVERYWHERE *  but then they cannot be “*REQUIRED FOR ALL WEBSITES"*.
>
>
>
> WE CAN WISH IT WEREN’T SO   — but we can’t make it not so…
>
>
>
>
>
> I am as frustrated as anyone — except those that must deal with this
> reality every day.  for them the frustration is immensely greater.
>
>
>
> but lets not have frustration at facts - blurr our vision.    or we will
> not see clearly that which we can do.  or we will poison the the things
> that can be there — with things that can’t - and they will not take any of
> it up and use it.  they won’t be able to.
>
>
>
>
>
> *g*
>
>
>
> Gregg C Vanderheiden
>
> greggvan@umd.edu
>
>
>
>
>
>
>
> On May 26, 2017, at 2:19 AM, Milliken, Neil <neil.milliken@atos.net>
> wrote:
>
>
>
> -5
>
>
>
> Speaking as a person with a cognitive disability I don't agree. Assistive
> technologies like speech recognition and text to speech when I need it are
> very useful but a pain and many of the issues that I and millions of others
> face daily could be solved without the need to use AT.
>
>
>
> If you add an AT extra layer into the mix you frequently add to the
> cognitive load certainly at the beginning - the learning curve is can
> appear cliff-like for some users with cognitive disabilities which is why
> it's so critically important to address the issues at source and not try
> and sticking plaster it with AT. Furthermore there is plenty of evidence of
> abandonment of AT.
>
>
>
> Make better products, design clearer websites don't push people to adopt
> extra tools to deal with what is essentially poor design.
>
>
>
> Kind regards,
>
>
>
> Neil Milliken
>
> Head of Accessibility & Digital Inclusion
>
> Atos
>
> M: 07812325386
>
> E: Neil.Milliken@atos.net
>
> http://atos.net/iux
>
> http://atos.net/accessibilityservices
>
> @neilmilliken
>
>
>
>
>
>
> On 26 May 2017, at 03:33, Gregg C Vanderheiden <greggvan@umd.edu> wrote:
>
> +5
>
>
>
> *g*
>
>
>
> Gregg C Vanderheiden
>
> greggvan@umd.edu
>
>
>
>
>
>
>
> On May 25, 2017, at 9:02 AM, David MacDonald <david100@sympatico.ca>
> wrote:
>
>
>
> To me the biggest gap in getting the needs met for people with Cognitive
> disabilities is a killer AT. Early in computing innovative people serving
> the blind rolled up their sleeves and did the hard work necessary to invent
> a technology that revolutionizes the lives of people with disabilities.
> Building on that partnership, WCAG 1.0 provided guidance to authors to
> optimize the use of screen readers on the web.
>
>
>
> We can bring the plumbing to the door, as we tried to do in WCAG 2,
> http://davidmacd.com/blog/wcag-for-low-vision-cognitive-disabilites.html
>
>
>
> but I think ultimately the break through for people with Cognitive
> disabilities will be software that analyses language, and UI's and delivers
> content in a way that is simplified or specialized, we can piggy back on
> that with requirements that optimize the use of this AT on the web.
> Unfortunately, this is speculation right now, and unlike 1998 when there
> was 10 years of screen reader history, we have no history of this
> theoretical AT.
>
>
>
> Inventors, where are you? and where have you been for 25 years?
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
> On Thu, May 25, 2017 at 7:29 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> Gregg wrote:
> > if there are supplemental docs — I think that each should focus on ONE
> aspect -  and not be written anything like WCAG  (or else it will be very
> confusing and not very useful or used)
> >
> > the supplement should NOT be   WCAG without testability.   Because there
> is no use for that.
>
> I disagree with that assumption, but perhaps we are talking along
> different lines. Let’s start with some agreements and see where we diverge:
>
> 1. Given how difficult it is to create testable criteria for things we
> know improve the experience for people with cognitive issues, do we agree
> that *something* beyond WCAG 2.1 is needed?
>
> Lisa has been clear that she believes putting things at AAA means they
> might as well not be there. I somewhat disagree, but see where that comes
> from and it removes a possible approach.
>
> 2. If we agree we need something, does that something need to be before
> Silver? I think most people would agree it does.
>
> 3. If we need something in the WCAG 2.1 timeframe, what form does it take?
>
> In my mind the motivation / aim is to create something for organisations
> which have a public service mandate (e.g. Governments, medium-large
> corporates etc.) so they can do more to make things accessible for more
> people.
>
> These are organisations where “reasonable effort” could include usability
> testing, following a UCD process, and getting external WCAG compliance
> testing etc. Compared to small and/or niche organisations where such effort
> would be unreasonable (but they should still be able meet WCAG 2.1 by
> improving their content in accordance with the 2.1 SCs).
>
> In the extended guidance we could include things which use terms like
> “When appropriate…”, e.g:
> http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/
> adjustability
>
> For example, something I include in training but isn’t covered by WCAG is
> making it apparent that you’ve performed an action when the reaction is
> spatially separated (e.g. you click “add to basket”, and the only thing
> that changes is a number in the top-right of the screen).
>
> I hadn’t even considered putting that forward as an SC, partly because of
> testability concerns, and partly because it usually gets caught in
> (general) usability testing anyway.
>
> However, with looser language it would be quite feasible to include that
> aspect, and things like Plain language (avoid jargon, double-negatives
> etc.) without having to worry about word lists.
>
> I think it should avoid ‘conformance’ language, but it makes sense to use
> a structure that mirrors POUR, has guidelines, and the next level down
> would be something like heuristics instead of SCs.
>
> If that is framed as something for organisations to follow when they have
> sufficient resource and a mandate to do so (e.g. for Government
> institutions), then it could be very useful.
>
> Kind regards,
>
> -Alastair
>
>
>
>
>
> Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are
> trading names used by the Atos group. The following trading entities are
> registered in England and Wales: Atos IT Services UK Limited (registered
> number 01245534), Atos Consulting Limited (registered number 04312380),
> Atos Worldline UK Limited (registered number 08514184) and Canopy The Open
> Cloud Company Limited (registration number 08011902). The registered office
> for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No.
> for each is: GB232327983.
>
> This e-mail and the documents attached are confidential and intended
> solely for the addressee, and may contain confidential or privileged
> information. If you receive this e-mail in error, you are not authorised to
> copy, disclose, use or retain it. Please notify the sender immediately and
> delete this email from your systems. As emails may be intercepted, amended
> or lost, they are not secure. Atos therefore can accept no liability for
> any errors or their content. Although Atos endeavours to maintain a
> virus-free network, we do not warrant that this transmission is virus-free
> and can accept no liability for any damages resulting from any virus
> transmitted. The risks are deemed to be accepted by everyone who
> communicates with Atos by email.
>
>
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>