Re: Can Silver have normative technology specific requirements?

My hope for Silver is that it is as technology agnostic as possible – regardless of what section of a document or whether it is normative or informative. The guideline is to support people.

Take for example, even implied technology. SC 1.3.4 implies phones and tablets and assumes 2 dimensions and 2 named orientations. This does not account for orientation of the agent/client within (picture-in-picture; snap mode; multitasking); or spanning multiple screens; or transparent screens that can be operated from the back; or flexible displays; or augmented or mixed or virtual reality; or {n} number of new technology-specific contexts. But none of those devices or screens or views within screens is the point. People are. Can we move toward guidance that just says something closer to “no digital content should be restricted by a specific viewing context”? And then define context in a way that focuses on the human and not the technology?


Charles Hall // Senior UX Architect

charles.hall@mrm-mccann.com<mailto:charles.hall@mrm-mccann.com?subject=Note%20From%20Signature>
w 248.203.8723
m 248.225.8179
360 W Maple Ave, Birmingham MI 48009
mrm-mccann.com<https://www.mrm-mccann.com/>

[MRM//McCann]
Relationship Is Our Middle Name

Ad Age B-to-B Agency of the Year, 2018
Ad Age Agency A-List 2016, 2017
Ad Age Creativity Innovators 2016, 2017
North American Agency of the Year, Cannes 2016
Leader in Gartner Magic Quadrant, 2017, 2018



From: Wilco Fiers <wilco.fiers@deque.com>
Date: Thursday, November 22, 2018 at 3:40 PM
To: David MacDonald <david100@sympatico.ca>
Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, Silver Task Force <public-silver@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: [EXTERNAL] Re: Can Silver have normative technology specific requirements?
Resent-From: Silver Task Force <public-silver@w3.org>
Resent-Date: Thursday, November 22, 2018 at 3:40 PM

Hey David,
Do you think, with such a guidelines / methods solution, that AG could reliably produce and maintain enough methods for enough technologies? That is my biggest concern about this. Yes, technology specific measurable methods would be fantastic, but it is very resource intensive to develop and maintain them. That's effectively what ACT Rules are, and it's a complex and resource intensive task to keep those up to date, let alone develop new ones.

W

On Thu, Nov 22, 2018 at 9:14 PM David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
Patrick asks:
> I thought the point of non-normative techniques was that what really
counts is fulfilling a success criterion, and that to do that, there can
usually be more than one particular way of doing that...hence the
techniques being non-normative ("here's one way of doing it" versus
"this is the one true way you HAVE to do it"). If anything, with more
standards/technologies coming around now, this holds even more true than
before. Unless I'm missing a nuance here?

David:
Its true that one advantage of separating the SCs from the techniques was that it left room for authors to create their own techniques. However, that could also be done if we were to integrate the techniques and success criteria. We could have say, 5 technology specific methods and then a sixth method could look like a technology agnostic WCAG 2 SC to cover any outlier situations. Most people will ignore the last cryptic technology agnostic method ard follow the easy to understand technology specific methods.

The main reason we separated SCs from techniques, as I remember, was to overcome the problem of having a long term stable standard which didn't need revisions in an environment where technology is changing. But the new W3C requirement of frequent updates provides us with the opportunity to not have them separated because the constantly updated standard can keep up with the constantly updating technology.


Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613-806-9005

LinkedIn
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_davidmacdonald100&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=Gwcbi9MfHzPpYCsOBJhcoKIW-Bu5P7G-ON02XcnUATI&e=>

twitter.com/davidmacd<https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_davidmacd&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=uocXZOc_Yk-4YWIZi-oXfWzekm0hm8XLnfYRAHaNId0&e=>

GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DavidMacDonald&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=rOqI-AUBHcakA8h4jSF-C3kwJS1C_g4GTeLXr1fCPAM&e=>

www.Can-Adapt.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.can-2Dadapt.com_&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=Th3jR2tjL-OUJeaMTnhmka005EwYYrvSJQ2mbFdrm4U&e=>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidmacd.com_disclaimer.html&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=ytDjulLR5Kc_9h17qJwL4m5DOzko5l_VkvgmQCNzYpQ&e=>


On Thu, Nov 22, 2018 at 1:24 PM Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
On 22/11/2018 16:22, David MacDonald wrote:
> Brainstorming has begun about what the next major version of the WCAG
> may look like. This is an attempt to contribute to that process, with
> its historical perspective as a consideration.The universal response to
> the WCAG appears to be that it has made an amazing impact on global
> accessibility and is a unified standard around which the global
> community can rally. However, it is difficult to understand and it’s
> technology agnostic language sometimes seems cryptic to those who are
> implementing it on their sites. Almost all of the criticisms of the WCAG
> 2.0 can be boiled down to “its hard to understand” and “it needs to make
> room for soft requirements that are hard to test”.
>
> To explorehow we got here, let’s go back to 1999, with the release of
> WCAG 1.0. It was a breakthrough standard in which design concepts such
> as colour, and HTML specific requirements were all mixed together in a
> very flat level standard. It was a huge success and began to get legal
> recognition. One of the things that led to its quick adoption was that
> it was easy to understand, and it made a big difference for people with
> disabilities.However, it was very prescriptive on designers and was also
> vulnerable to changes in technology. Legal frameworks and standards
> historically move much slower than technology.
>
> We endeavoured to solve this problem in WCAG 2.0. The W3C process was
> that normative documents went through a long rigorous process to become
> a standard(years). There is also a category of supporting documents that
> were non normative and easier to update. WCAG 2.0 extractacted the
> characteristics of the 1.0 requirements into technology agnostic
> normative success criteria, withseparate non normative technology
> specific techniques to meet those success criteria.It was a huge success
> and WCAG 2.0 has survived 10 years. But its longevity and stability came
> at a high cost. It had 4 layers, 3 layers were normative (Principles,
> Guidelines, Success criteria) an one layer (technology specific
> techniques) that were non normative.
>
> In the last few years the W3C has evolved in its approach to standards
> for a more iterative approach perhaps inspired by AGILE. There is a
> requirement now for standards to be frequently updated on 18 month - 2
> year cycles. No more 10 year development cycles such as we had in WCAG
> 2.0. At first I was concerned that this change in approach would cause
> problems for future of WCAG.
>
> However, during TPAC I realized that frequent updates to the standard
> could solve the dilemma of separation of normative success criteria and
> non normative technique where users had to look in 2 places. Frequent
> published standards could keep up with technology. So we might be able
> to integrate the techniques into the *normative* part of the standard
> and merge them with the testable/measurable Success Criteria, into what
> the Silver Task Force is calling “methods”. These would be normative.
> The WCAG 2.0, 12 guidelines would expand in their role and become
> general guidelines under which these methods could be grouped. So
> instead of 4 layers of guidance which cause the reader to look in
> several places to know what to do, there would be only 2 layers
> (Guidelines and Methods). It would overcome the problem of having to
> have technology agnostic success criteria which are hard to understand.
> The methods would say what to do and how to do it and also be the unit
> of measurement of conformance. There would be only one place to lookin
> order to know what to do to meet the requirement.
>
> So I'm suggesting we explore moving integrating the techniques with the
> SCs to become *normative* methods that are updated using the regular 18
> month-2 year cadence of the normative document cycle.  The general
> information such as "Make code correspond to visual layout" would be
> guidelines under with all of the methods rest.

I thought the point of non-normative techniques was that what really
counts is fulfilling a success criterion, and that to do that, there can
usually be more than one particular way of doing that...hence the
techniques being non-normative ("here's one way of doing it" versus
"this is the one true way you HAVE to do it"). If anything, with more
standards/technologies coming around now, this holds even more true than
before. Unless I'm missing a nuance here?

P
--
Patrick H. Lauke

www.splintered.co.uk<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.splintered.co.uk&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=0t4ZU2zp7VNcVjpH7E7D48ektjYi3PpjuzO1gOGt4ss&e=> | https://github.com/patrickhlauke<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_patrickhlauke&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=dVWiYb256gpGNoB1TlzhSo4AslkJPxeCGqrranM2IOg&e=>
http://flickr.com/photos/redux/<https://urldefense.proofpoint.com/v2/url?u=http-3A__flickr.com_photos_redux_&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=p44D5rnaN7eWTkn-elMiP0tfGXKf7kK-kqRPiJHFEZo&e=> | http://redux.deviantart.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__redux.deviantart.com&d=DwMFaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=c3Kw6ildyXXZq0p5mIVJkDVhf2muVEp0uN07v7TNBP0&s=pkLdcGlzmZMl9kCDvThk_Gl5MxAutxtPkoXyyBTTRIY&e=>
twitter: @patrick_h_lauke | skype: patrick_h_lauke


--
Wilco Fiers
Senior Accessibility Engineer - Co-facilitator WCAG-ACT - Chair Auto-WCAG
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]

This message contains information which may be confidential and privileged. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message.  If you have received the message in error, please advise the sender by reply e-mail, and delete the message.  Thank you very much.