Re: Following properly documented existing procedures - A hypothetical question?

Hi Detlev,

Thanks for these clarifications, they are useful for the development of 
the "web accessibility tutorials" that we are working on separately:
  - http://www.w3.org/WAI/tutorials/

Some further thoughts inline below.


On 20.11.2013 11:45, Detlev Fischer wrote:
> Hi Shadi, see my clarification below.
>
>>> On 18.11.2013 21:23, Detlev Fischer wrote:
>>> > Take the headings techniques G141 and H42
>>> (http://www.w3.org/TR/WCAG-TECHS/G141.html and
>>> http://www.w3.org/TR/WCAG-TECHS/H42.html). While you may think it is
>>> clearly implied here that headings should be used to reflect the
>>> hierarchy, checks in both techniques refrain from requing correct nesting,
>>> and F2 has a somewhat ambiguous check ('Check that the proper
>>> semantic structure (e.g., HTML headings) is used with the text to convey
>>> the information') which can be interpreted both ways (A) just check
>>> headings are marked up with h1-h6 regardless of flawless hierarchy, or (B)
>>> checking any heading mark-up in the context of the overall structure
>>> (including content headed).
>
>> Correct, there is no requirement for *nested headings* but there are
>> requirements on *reflecting the structure* (which may or may not be
>> hierarchical). Also Success Criterion 1.3.2 is relevant here.
>>
>> So, I really don't see how you could come to interpretation (A) even
>> when you only consider Success Criterion 1.3.1. It requires that all
>> 'information, structure, and relationships' are made programmatically
>> determinable. With checking for (A) you only check 'information'
>> but omit 'structure' and 'relationships' from the same
>> Success Criteria.
>
> In my experience, testers will often come to different conclusions when checking less-than perfect heading/content structures. Examples where judgements (in a level AA test) tend to divert are:
> (1) The overall heading structure is fine, but some longish content is structured with <strong> on leading inline headings. Some testers will argue these should be marked up as, say, h5 even though they are rendered inline, others would argue <strong> *is* semantic markup (even when ignored by screen readers) and the requirement for section headings in longish content would in any case only exist on level AAA (SC 2.4.10 Section Headings)

Right. This is inherent and probably not easily resolvable. The issue is 
really interpreting the *content* rather than the *requirement*. That 
is, what is the semantic as opposed to how should it be marked up.


> (2) Heading structure is hierarchical and consistent, but at some places heading levels are consistently skipped, i.e. going straight from h2 to h4, for example. Big deal? Some think not, others will see a violation.

Or <h2>'s for header and navigation preceding an <h1>. True. This could 
be better explained, I guess. Maybe the tutorials could help.


> (3) On a page there is an isolated minor flaw in applying the correct heading level, possibly motivated by the wish to achieve a particular styling. The flaw does not really make a big difference though. Fail the page for that?

This relates to conformance. As of now, a flaw is a flaw according to 
WCAG. There is no minor, mild, and big categorization.


> (4) You find that h3 content subheadings are followed by h3 page footer headings so while the structure overall is sound, there really should be an invisible h2 for the footer section that would tell screen reader users they have left content and entered the sitemap-type footer (2.4.1 is OK however, there are skiplinks and/or aria landmarks for navigation, main, footer). Big deal? Fail a page for that? Opinions will differ.

Right. But that is really just another situation/instance of (2).


> The point I am trying to make is that real world content often leads to different tester judgements *even in cases where a group of testers tries hard to apply the same well documented criteria*. Documentation just cannot cover every instance you find in real word content. So it really depends on your strictness and/or your estimation of impact whether or not you will decide to pass a page in spite of flaws. And as described above, some will see flaws where others think the solution is perfectly accceptable. (To labour my point, BITV-Test will fortunately allow you to assign a 'near pass', 'partial pass' or 'near fail' to reflect the frequent cases of less-than-perfect content - not so the WCAG concept of conformance.)

I agree but we are moving away from "common procedures" topic towards 
"weighted failures". I think this is a project on its own. Maybe a 
future extension to the methodology when we have better defined ways?

Best,
   Shadi


> Cheers,
> Detlev
>
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
>
> Mobil +49 (0)1577 170 73 84
> Tel +49 (0)40 439 10 68-3
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
> Shadi Abou-Zahra schrieb am 19.11.2013 14:03:
>
>> Hi Alistair, Detlev,
>>
>> Please find some thoughts on different parts of the thread, sorry if
>> they are quoted out of context. Here is the link to the full thread:
>> - http://lists.w3.org/Archives/Public/public-wai-evaltf/2013Nov/0020
>>
>>
>> On 18.11.2013 17:54, Alistair Garrison wrote:
>> &gt; My question is this - &quot;Am I honour bound to follow the procedure
>> they have documented?&quot;
>>
>> Depends on what you want to do. Do you want to validate that what they
>> said is correct versus the approach that they are following is correct.
>>
>>
>> &gt; The thought in my head is yes - that I should follow their procedure
>> if it is properly documented.  I would of course check all relevant
>> failure conditions, but if I didn&#039;t follow their procedure and
>> started to test the page using tests from sufficient techniques I&#039;ve
>> chosen (which have not been used to develop the web content) I might find
>> a failure or two - just because they have done things differently.
>>
>> Ideally different procedures would not diverge. If they do then:
>>
>> #1. One or both procedures are incorrect interpretations of WCAG 2.0
>> Success Criteria;
>>
>> AND/OR
>>
>> #2. The guidance around WCAG 2.0 Success Criteria for which the two
>> procedures diverge is too vague;
>>
>> Feedback on #2 should be made to the WCAG WG so that they can improve
>> their guidance; for example in &quot;Understanding WCAG 2.0&quot;
>> documentation.
>>
>>
>> On 18.11.2013 21:23, Detlev Fischer wrote:
>> &gt; Take the headings techniques G141 and H42
>> (http://www.w3.org/TR/WCAG-TECHS/G141.html and
>> http://www.w3.org/TR/WCAG-TECHS/H42.html). While you may think it is
>> clearly implied here that headings should be used to reflect the
>> hierarchy, checks in both techniques refrain from requing correct nesting,
>> and F2 has a somewhat ambiguous check (&quot;Check that the proper
>> semantic structure (e.g., HTML headings) is used with the text to convey
>> the information&quot;) which can be interpreted both ways (A) just check
>> headings are marked up with h1-h6 regardless of flawless hierarchy, or (B)
>> checking any heading mark-up in the context of the overall structure
>> (including content headed).
>>
>> Correct, there is no requirement for *nested headings* but there are
>> requirements on *reflecting the structure* (which may or may not be
>> hierarchical). Also Success Criterion 1.3.2 is relevant here.
>>
>> So, I really don&#039;t see how you could come to interpretation (A) even
>> when you only consider Success Criterion 1.3.1. It requires that all
>> &quot;information, structure, and relationships&quot; are made
>> programmatically
>> determinable. With checking for (A) you only check &quot;information&quot;
>> but
>> omit &quot;structure&quot; and &quot;relationships&quot; from the same
>> Success Criteria.
>>
>> What am I missing here?
>>
>> Best,
>>    Shadi
>>
>> --
>> Shadi Abou-Zahra - http://www.w3.org/People/shadi/
>> Activity Lead, W3C/WAI International Program Office
>> Evaluation and Repair Tools Working Group (ERT WG)
>> Research and Development Working Group (RDWG)
>>
>
>

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG)

Received on Wednesday, 20 November 2013 14:11:51 UTC