Re: Can Silver have normative technology specific requirements?

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

That is probably the biggest challenge of having a menu (as in cafeteria
menu) of methods. Perhaps the answer for complicated guidelines is
"whichever of these methods apply to meet the guideline's objectives",
which feels a bit squishy.

Perhaps one way to overcome that is to break up guidelines that are
composites like 1.3.1.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613-806-9005

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 Tue, Nov 27, 2018 at 8:03 AM Detlev Fischer <detlev.fischer@testkreis.de>
wrote:

> 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 <david@can-adapt.com>]
>
> *Sent:* maandag 26 november 2018 23:35
> *To:* Jeanne Spellman <jspellman@spellmanconsulting.com>
> <jspellman@spellmanconsulting.com>; Wilco Fiers <wilco.fiers@deque.com>
> <wilco.fiers@deque.com>
> *Cc:* Silver Task Force <public-silver@w3.org> <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
>
> 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> 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
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virenfrei.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_3724620069567378268_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>