Re: Further example for F69

Hi Adam, hi group,

The question foremost on my mind is whether the decision that supporting 
page zoom is sufficient for passing SC 1.4.4 is final, or may evenually 
be re-negotiated in further revisions of WCAG. (Just an aside: It was 
interesting to note that some browsers on Android phones support text 
resizing).

My understanding is that the SC in the normative text:

"1.4.4 Resize text: Except for captions and images of text, text can be 
resized without assistive technology up to 200 percent without loss of 
content or functionality. (Level AA)"

...does no prejudice the options given in the Sufficient Techniques for 
1.4.4.

Since this document contains references techniques (a moving target), it 
cannot itself be normative, at least not in the same sense as the core 
recommendations. Correct?

In this light, the fact that G142 alone (Using a technology that has 
commonly-available user agents that support zoom) is deemed sufficent to 
meet the SC 1.4.4 is, as I see it, not more than the current consensus 
of the WCAG working group. This consensus is, I believe, not immutable 
or irreversible - correct?

Having said that, I realise that the increasingly small numbers of UA in 
use that do not support page zoom may suggest that a reversal of the WG 
position is unlikely.

For our accessibility evaluation procedure, BITV-Test (a scheme based on 
WCAG level AA with minor deviations) the recent clarification has quite 
an impact.
So far, we have taken the existence of F69 and the examples within it 
which indicated that this failure was (also) about text-only resizing as 
a point of reference and rationale for including a checkpoint that tests 
just that: that text resizing works (to a degree: we settled for an 
easier-to-meet factor of 150%). This had also ensured continuity with 
the old BITV directive and corresponding test procedure which had 
demanded support for text resizing so far.

The current deliberations and clarifications in the WCAG WG leading to 
the point where F69 may be deleted altogether have removed an important 
point of reference, so we are now discussing whether the checkpoint for 
text-resizing is still tenable or should be deleted. (To be sure, there 
is a large user group of elderly and visually impaired people greatly 
benefiting from text-only resizing, so we will also discuss the issue 
with organisations of blind ansd visually impaired people before 
deciding whether to axe the checkpoint.)

As far as the value of failures is concerned, they are of great benefit 
in setting up evaluation procedures (as in the current EVAL task force) 
since they define clearly, and *beyond individual techniques* , when a 
failure occurs. Test in techniques are never equally conclusive due to 
the usual disclaimer that another technique may be used to meet the SC.

So from an evaluation standpoint, it is highly valuable to have a 
failure even if it cannot be unambiguously linked to a certain 
technique. The failure examples for F69 are a point in case. Overlaps 
and cut-off content may as a consequence of any number of technique 
used, such as setting container widths in percent or the careless use of 
absolute positioning. From an evaluation standpoint, it is not necessary 
to know *why* (based on what technique) a failure may occur - this is 
sometimes difficult to establish, as when content is dynamically generated.

BTW, I am not sure that the argument that failures should be generic, 
i.e. avoid reference to particular technologies, is applied throughout 
the set of available WCAG failures. Some at least explicitly refer to 
HTML elements and attributes or standards such as CSS. While it may be 
preferable to phrase failures in a technology-agnostic manner, I see no 
harm in being specific where appropriate. At least it is helpful from an 
evaluation perspective to be able to anchor a procedure in failures 
wherever possible.

Regards,
Detlev



Am 15.11.2011 21:15, schrieb Adam Solomon:
> I would like to explain my perspective on the issue of F69, and why the
> group had tentatively decided to table this failure, in the hopes of
> avoiding an unnecessarily long discussion of this issue at the next meeting.
> Originally, the examples from F69 violated the success criterion only when
> using text resize, but when using zoom, no text or content was lost. Since
> zoom is a valid way of satisfying the success criterion, these examples were
> essentially obsolete for this failure. The group then tried to rewrite F69
> to indicate that the examples would only fail when text resize was being
> used as the technique for this success criterion, but that with zoom the
> failure would not apply. At that point we realized that the test procedure
> was also misleading. It states that if one resizes the text and content is
> lost, there is a failure. In fact, one might test with text resize and find
> that content is lost, and conclude that there is a failure, when, in fact,
> there is no failure at all, since zoom can be used to resize without loss of
> content. The group tried a few stabs at rewriting the test procedure, but
> was unable to reach a consensus on any of the drafts that were suggested.
> All of them seemed to leave room for confusion.
> So, there are really two issues at hand:
> 1. Getting examples of content loss which fail in zoom, as well as text
> resize. Thanks to James, Kathy, and now Detlev, we have these examples.
> 2. Rewriting the test procedure in a way which will leave no doubt that
> there is no failure when zoom is used without content loss. This is the
> greatest of the two problems.
> Though most of the group was wary of throwing away valuable examples, we
> decided that the suggested rewrites for the F69 test procedure were not
> clear enough.
> It is my feeling that unless we make it crystal clear in the test procedure
> that zoom can satisfy the SC, then we do need to delete F69. This is a
> technology specific failure, and there is a precedent for such a deletion:
> (to the best of my recollection) a similar failure was deleted - I believe
> it was F68 (though I didn't find the minutes for this), because it was
> technology specific, namely ARIA provided a way of associating a label with
> a control field.
>
>
> -----Original Message-----
> From: Detlev Fischer [mailto:fischer@dias.de]
> Sent: Tuesday, November 15, 2011 1:22 PM
> To: w3c-wai-gl@w3.org
> Subject: Further example for F69
>
> I tried my hand at a further example for failure F69 that works in both
> text zoom and page zoom, this time involving an absolutely positioned
> header box.
>
> http://www.oturn.net/wcag/failure-1.4.4.html
>
> Probably needs further work but seems to demonstrate failure in both IE
> and Firefox, also in Opera and Chrome.
>
> Talk to you an Thursday,
> Detlev
>
>
> Am 14.11.2011 23:17, schrieb Loretta Guarino Reid:
>> We'll reopen the discussion around F69. We will take advantage of
>> Detlev's presence to review his latest failure proposals. Please send
>> any other items we should take up on Thursday.
>
>


-- 
---------------------------------------------------------------
Detlev Fischer PhD
DIAS GmbH - Daten, Informationssysteme und Analysen im Sozialen
Geschäftsführung: Thomas Lilienthal, Michael Zapp

Telefon: +49-40-43 18 75-25
Mobile: +49-157 7-170 73 84
Fax: +49-40-43 18 75-19
E-Mail: fischer@dias.de

Anschrift: Schulterblatt 36, D-20357 Hamburg
Amtsgericht Hamburg HRB 58 167
Geschäftsführer: Thomas Lilienthal, Michael Zapp
---------------------------------------------------------------

Received on Wednesday, 16 November 2011 09:21:54 UTC