RE: Extension conflict/compatibility requirement

Ø  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<mailto: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<mailto: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<mailto:gregg@raisingthefloor.org>> wrote ----

On Oct 25, 2015, at 10:46 PM, lisa.seeman <lisa.seeman@zoho.com<mailto: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