RE: Can Silver have normative technology specific requirements?

Thanks David,

Ok, so there will be normative methods and at the end a fall back method / SC (speaking in current WCAG language).

But is one method enough to comply? Or do you need to do two? Or a specific combination?

So, when is a method sufficient (for a guideline) as more than one may be needed to make something accessible?

Like:

1.     ARIA11: Using ARIA landmarks to identify regions of a page<http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/ARIA11> (ARIA)
2.     ARIA12: Using role=heading to identify headings<http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/ARIA12> (ARIA)
Is 1 enough, or both are needed?
You might end up in an endless combination of possibilities.

Cheers!
Jake

From: David MacDonald [mailto:david@can-adapt.com]
Sent: maandag 26 november 2018 23:35
To: Jeanne Spellman <jspellman@spellmanconsulting.com>; Wilco Fiers <wilco.fiers@deque.com>
Cc: Silver Task Force <public-silver@w3.org>
Subject: Re: Can Silver have normative technology specific requirements?

Hi Jeanne

As requested, I've updated the 1.3.1 model to demonstrate what I mentioned about using something similar to the current SC language as the last "catch all" method for each guideline. The idea is overcome the concern that by making the methods part of the standard that we'd have to supply an endless array of techniques in order to keep up with technology and address every edge case.

So at the end of the methods for each guideline, there would be a fallback "catch all" method that would basically look like current a WCAG success criterion. A testable statement that is technology agnostic. It would have some of the detrimental aspects of current SCs, in that they would be technology agnostic and passive tense testable statements that could be referred to in situations where none of the methods are sufficient.

The usefulness of this is that stakeholders could refer to this method when creating their own techniques, so they can have flexibility and do not have to be confined only to our prescribed methods, they can cite this method and make up their own... and yet have the same obligations of making sure it meets the method's requirements.

This catch all method could also be a funnel for new methods because a developer could create a technique under this method and use it right away, and submit it as a possible method to add to our list methods.

This transfers the cryptic language to the end of a long list of methods.  Most devs can ignore it, unless none of the other methods work for them.

http://davidmacd.com/WCAG/silver/information-relationships.html

See method #11

Cheers,
David MacDonald



CanAdapt Solutions Inc.
Mobile:  613.806.9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://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 Mon, Nov 26, 2018 at 11:41 AM Jeanne Spellman <jspellman@spellmanconsulting.com<mailto:jspellman@spellmanconsulting.com>> wrote:



Thu, 22 Nov 2018 15:13:23 -0500, David MacDonald wrote:

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.

This is a interesting idea that could potentially solve some of the edge cases that have come up in discussion.

David, would you add this idea to your prototype example? Or write a new one if it doesn't apply.  That will give us a concrete example to discuss and test.

On 11/23/2018 8:47 AM, Alastair Campbell wrote:
I think it would be best to define the optimal structure for practical use, then work out what should be normative secondly.

+1

That's why it is so important for people to stress test the architecture prototype and the plain language prototype.  That's what will help ensure that we have the optimal structure.  Please don't forget to test  the proposals that did not make it into 2.1.  We aren't writing content yet, so don't be concerned about the writing -- just sketch it out.  Instructions and links are in this email:
https://lists.w3.org/Archives/Public/public-silver/2018Nov/0040.html


If you are looking for inspiration, this is a copy of spreadsheet that David did of SC Not accepted for 2.1:  https://docs.google.com/spreadsheets/d/1XShLFX8fxHYYLn8A6avDwu37w9JfnZCGWvAKBpK9Xo4/edit#gid=264773938






-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------