Re: In WCAG NEXT let's put a date field on failures

Hi Alestair

I did not fail sites on 1.3.1 on not making Headers, footers, navigation,
and main content programatically determinable before the advent of Landmark
​s and HTML and I still don't although I point out that they should do
this. and give that an issue number as an important practice, with minimal
investment and high returns. So clients do it, some clients say, "just give
me the failures"

WCAG is supposed to be ever green and technologically independent to give
it a longer life. That's why we decided to make the very difficult decision
to remove any mention of technology in the SCs. If we can't keep up with
the most basic important accessibility feature such are regions, then we've
failed at that goal... There are very few sites existing today on the web
that we'd be asked to evaluate that were made before Landmarks were in
mainstream use around 2010. (6 years ago).

Anyway, my proposal was kind of a test. The "ever green" strategy of WCAG 2
failed for failures (and worked for techniques). So we need to address this
in 2.1, and I'm glad that the feedback about provide a date field in
techniques has been positive. It's a small thing, but might help solve the
problem moving forward.

I'm really hoping we don't adopt the squishy policy of not providing
failures in WCAG Next.  I think WCAG would have been a failure without the
common failures.... they are used by tools, by authors, by banks some of
which told me that's all they look at :(   ... They are critical to the
clarity required about common ways authors mess up. Failures are a bright
line in the sand. They are not squishy like the success criteria can be,
full of exceptions that require expert interpretation, where one can argue
about whether 1.3.1 Info and Relations really means blind people should not
have information about the relationship between a footer, nav, and the main
body.

I'm willing to table the failure to WCAG NEXT, with the confidence that we
won't drop the ball on failures.


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

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 Wed, Apr 27, 2016 at 4:33 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi David,
>
> I didn’t express it very well on the call, but I think my core objection
> to the failure technique is that it changes (in practice) the results of
> testing a page.
>
> Question: In the period between WCAG 2.0 being released and ARIA landmarks
> becoming well known / used (to any degree), did you fail pages that did not
> use a heading or text to identify regions of the page like headers, footers
> etc?
>
> I know I didn’t.  I promoted the use of headings (hidden if necessary) to
> identify navigation and other page furniture, and emphasised that a
> document should make sense when read without styling (which has a similar
> effect).
>
> However, pre-landmarks I did not have the concept of page-regions in the
> same way as I do now. We were missing the concept and standardised terms
> for regions of the page, not just the implementation. Therefore I didn’t
> fail pages that did not identify regions of the page.
>
> So in my mind adding a failure for this is an effective change to what the
> SC had meant in practice.
>
> On adding dates: Sure, an approved date seems like a good idea, presumably
> the technique (or even failure ;-) shouldn’t substantively change once it
> has been approved then?
>
> Cheers,
>
> -Alastair
>
>
>
>
>
> On 26/04/2016, 20:37, "David MacDonald" <david@can-adapt.com> wrote:
>
> >Today I proposed a failure that I wrote up in issue 173.
> >https://github.com/w3c/wcag/issues/173
> >It to ensure authors identify regions of a page programmatically (or with
> text).
> >We did not gain consensus and I am dropping the proposal in this
> >version of WCAG.
> >
> >However, I think it points to a significant problem that we will have
> >to address in WCAG.NEXT. I would like to propose a solution.
> >
> >===Problem===
> >WCAG was created to be an ever green document. The SCs are not
> >technology dependent, non normative techniques and failures, can be
> >created to address new realities that we see on the ground as the web
> >develops. This has happened for techniques, but not failures. We have
> >created about 150 new techniques since 2008, and only *3* (three)
> >failures.
> >
> >It is not from a lack of failure proposals, there have been plenty in
> >8 years. However, it is almost impossible to gain consensus on a
> >failure, because there are always a some voices that will not want to
> >tighten things up, for various reasons, some of them I would agree
> >with in some situations. Here are the main reasons its hard to pass a
> >failure:
> >
> >1) Fear that it changes the requirements of WCAG
> >2) If not, a fear that there is a *percieved* change to WCAG
> >3) Fear that pages that once passed will not pass after a new common
> >failure is introduced.
> >
> >====Solution=====
> >Id' like to propose an "Approved date" field, to techniques and
> >failures, which would be populated when we gained consensus on a
> >technique or failure. This will give jurisdictions a tool to exempt
> >failures that were created after a site was built.
> >
> >Cheers,
> >David MacDonald
> >
> >
> >
> >CanAdapt Solutions Inc.
> >
> >Tel:  613.235.4902
> >
> >LinkedIn
> >
> >twitter.com/davidmacd
> >
> >GitHub
> >
> >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
> >
>