Re: Extension conflict/compatibility requirement

Agreed - failure techniques are more comprehensive and do raise the bar -
unfortunately we have had to remove some of them as technology develops and
provides additional techniques. So, we have actually found that failures
were becoming almost impossible to write, because instead of say "test for
the presence of alt in images", that became "test for the presence of alt
or aria-label or.. or.. or.. ad infinitum.  In practice, failures are going
to become scarcer as time goes along unless we come up with a brilliant new
template for writing full proof test procedures.

On Wed, Oct 28, 2015 at 3:25 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> Ø  Where techniques are alternatives for meeting (a part of) the SC, they
> are often still not fully equivalent, which may not be reflected in the
> tests that they carry.
>
>
>
> Well said Detlev, the lack of sufficient techniques relating to or
> failures of a technique are perceived as an endorsement, acceptance, or
> tolerance of a practice.  Wayne’s example of inline element semantics is
> one an example of this.
>
>
>
> One strategy we could use in addition to creating sufficient techniques is
> to create more failure techniques around the existing success criteria.
> Failure techniques require a higher bar but carry more weight as we have
> documented specific techniques that do not meet a criteria.  Yes, a person
> can meet the criteria through another technique but failures send a clear
> message.
>
>
>
> Jonathan
>
>
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com
>
> Phone 703.637.8957
> Follow us: Facebook <http://www.facebook.com/#!/ssbbartgroup> | Twitter
> <http://twitter.com/#!/SSBBARTGroup> | LinkedIn
> <http://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>
>
>
>
> *From:* Detlev Fischer [mailto:detlev.fischer@testkreis.de]
> *Sent:* Wednesday, October 28, 2015 4:26 AM
> *To:* lisa.seeman
> *Cc:* GLWAI Guidelines WG org
> *Subject:* Re: Extension conflict/compatibility requirement
>
>
>
> I think the difficulty for many when trying to understand the relationship
> between Success Criteria and Techniques lies in the fact that the SC is
> considered testable while the actual tests are part of the (only
> informative) techniques, of which there can be many for 'catch-all' SC like
> SC 1.3.1 "Info and Relationships" (1.3.1 covers markup in headings, lists,
> data tables, inline content, and more).
>
> Where techniques are alternatives for meeting (a part of) the SC, they are
> often still not fully equivalent, which may not be reflected in the tests
> that they carry. To give an example: using the Sufficient Technique
> "ARIA10: Using aria-labelledby to provide a text alternative for non-text
> content" to mark up headings in legacy content where native heading mark-up
> wasn't used will remedy the situation for screen reader users, but the test
> in the technique doesn't ensure that headings are also visually distinct.
>
>
>
> Given the complexity and variety of possible implementations, it is
> probably not surprising that gaps exist in the network of techniques used
> to meet SC. The issue remains that conformance is considered in relation to
> the SC, while a multitude of conformance tests are carried out  below the
> level of SC -  using informal technique. This often leads to a situation in
> testing that relatively minor faults impact-wise can lead to a judgment of
> "fail" on an important SC like 1.3.1 unless you apply what may be called
> "tolerances" in judgement: "There's this minor issue, but we let this
> pass". These tolerances are needed in practice, but remain undocumented by
> design (content either fails or passes).
>
>
>
> There is also no clear provision for testers what to do in cases where
> several sufficient techniques are used that might all qualify for meeting a
> SC but one would fail (say, a dysfunctional skip link in a page where
> landmarks or headings would meet the SC 2.1.4 "Bypass Blocks"). From a pure
> testing perspective, this is a pass, from a user perspective, an actual
> problem occurs (there is a skip link but it does not work).
>
>
>
> The gap between (technology-neutral) SC and testable Techniques is
> probably unavoidable but in my opinion, the concept of pass/fail
> conformance makes little sense on the level of granularity of Success
> criteria like 1.3.1 (I.e. It is not sufficiently informative for designers,
> developers, editors). Nothing to do about that in WCAG extensions but I
> hope the group can rethink granularity and the concept of conformance in
> some future WCAG 3.0.
>
> Detlev
>
>
>
> Sent from phone
>
>
> Am 28.10.2015 um 02:33 schrieb lisa.seeman <lisa.seeman@zoho.com>:
>
> Hi Gregg
>
> I think we need to qualify this that, in your opinion, we can not change
> the restrictions on an SC. When we discussed this at the last FTF the group
> choice was that we can change them in the extensions. As this is a group
> based on consensus i think that the W3C process is that that decision
> should stand unless the consensus changes.
>
>
>
> If the chairs feel that we need to reopen the discussion then I will be
> happy to add points to I think it is better to keep the same turms even if
> the restrictions are altered in the extensions. Otherwise I would table
> this for now. We both want to change the wording, where we can, to make it
> testable and  widely applicable, but without compromising quality of the
> advice given.
>
>
>
> Just to remind me. If there are testable sufficient techniques does that
> make the criteria testable?
>
>
>
> All the best
>
> Lisa Seeman
>
> Athena ICT Accessibility Projects <http://accessibility.athena-ict.com>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Mon, 26 Oct 2015 06:01:43 +0200 *Gregg
> Vanderheiden<gregg@raisingthefloor.org <gregg@raisingthefloor.org>>*
> wrote ----
>
>
>
> On Oct 25, 2015, at 10:46 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
>
>
>
> Hi Gregg
>
>
>
> When I met with WCAG (I think it was at the last FTF) it was agreed that
> we could change these rules/restrictions in the extensions. If WCAG decide
> to go back on that then we should have that as a separate and serious
> discussion. (Personally I thought the decision was the right  one.)
>
>
>
>
>
> Oh I agree.
>
>
>
> but you can’t use the old terminology (e.g. Success Criteria) if you want
> to use new rules.   Or rather - you can’t redefine the meaning of those
> terms.
>
>
>
> You also won’t be able to use “conformance” if you don’t have testable
> criteria that a person can use to ‘conform’  (i.e.  testable so they can
> know when they have conformed — and someone else can test and they will
> come up with the same conclusion)
>
>
>
>
>
> But as per the last email,  I don’t think you need to use SC or
> conformance in this document.  And I think you will create a much more
> useful one if you don’t.      Get this document with all of its ideas,
> techniques and advice out for those who want to make things more
> cognitively accessible.      THEN loop back and look to see what might be
> in the testable SC (not testable techniques - but SC) category.
>
>
>
>
>
> PS  I predict (*hope I am wrong* but I predict) that you will find it
> very difficult and have many arguments even amongst the group as you try to
> find things that would qualify as SC.      I personally think we need to
> make more ground on creating better AT that can use the “programmatically
> determined “provisions in the current WCAG to take content and re-present
> it in different formats for the wide range of people with cognitive,
> language, and learning disabilities.
>
>
>
>
>
> best
>
>
>
> Gregg
>
>
>
>
>
>