Re: Can Silver have normative technology specific requirements?

2.4.1 seems relatively straightforward and my understanding was always 
that any one suffient technique is sufficient on its own here (ven thoug 
ghome do less for sighted kb users).

More problematic will be things like SC 1.3.1 (but then that may be 
broken up into more manageable bits) - if ii is like now you would need 
to meet a Technique for headings markup (where applicable) AND list 
mark-up (where applicable) and table markup (where applicable) etc.

Detlev

Am 27.11.2018 um 13:04 schrieb Abma, J.D. (Jake):
>
> 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
>
> *Can**Adapt**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.
> -----------------------------------------------------------------

-- 
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg

Mobil +49 (0)157 57 57 57 45

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus