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.
See method #11

David MacDonald

*Can**Adapt* *Solutions Inc.*
Mobile:  613.806.9005


GitHub <> <>

*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy

On Mon, Nov 26, 2018 at 11:41 AM Jeanne Spellman <> 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:
> If you are looking for inspiration, this is a copy of spreadsheet that
> David did of SC Not accepted for 2.1:

Received on Monday, 26 November 2018 22:35:41 UTC