Re: Success criteria 1.4.4

I must say in my defense that I did not change anything in my e-mail client (I sent it from my iPad, where I cannot change anything).

In fact, I think that the line-spacing problem comes from pasting directly from WCAG documents. I myself have low vision and have sadly discovered that my message was unreadable with my default choice of font size, showing a real example of the kind of things SC 1.4.4 tries to avoid.

I apologise for this, and will take into account in the future and avoid pasting directly from Web pages.

Kind regards,
Ramón.

G F Mueden warned:

> I could not read Ramon Corominas's emai until I swithed to read in plain 
> text.
> On the other hand, that from GregVanderheiden enabled my choice of font and 
> was easy to read.
> This is a fine example of why I am here.  I get forty emails a day andonly a 
> half dozen disable my accessibility settings.  That it should happen here is 
> a bit like the shoemakers child ging barefoot.
> 
> The most frequet offenderd ar thw White House,the VA and the US Access Bd. 
> Hubris?
> 
> Replying to RC's message even disabled my choice of font for sending.  It is 
> too hard for me to resd and catch my errors.
> 
> My file, "Accessibility for Eye Readers" 11K, is available as an email 
> attachment on request to gfmueden@verizon.net
> 
> Most eye readers need only two fixes in their software >
> For poor acuity we need magnification with word wrad
> For poor contrast sensitivity we need choice of font for incoming text.
> We pray you our masters, with your formatting, don't disable these settings.
> 
> Be of good cheer.  G F Mueden  ==gm===
> 
> ----- Original Message ----- 
> From: "Ramón Corominas" <listas@ramoncorominas.com>
> To: <w3c-wai-ig@w3.org>
> Sent: Sunday, October 30, 2011 9:38 AM
> Subject: Re: Success criteria 1.4.4
> 
> 
> Hi all!
> 
> While re-reading this thread, I noticed this sentence from Felix:
> 
> "One need only raise the size of a 16px font to about 22.4px to get a 
> doubling of size. A doubling of a CSS "size" produces an nominal _size_ 
> increase of 400%."
> 
> This seems to consider "size" as the *area* of the block of text, which 
> would imply that an "increase of 200%" means "original font-height * 
> sqrt(2)"; but according to the Understanding SC 1.4.4 document:
> 
> "Content satisfies the Success Criterion if it can be scaled up to 200%, 
> that is, up to twice the width and height."
> 
> I've always interpreted that 200% means "original font-size * 2", but some 
> customers use the "area" argument to reduce the impact of this requirement 
> on their CSS, because "size" is not explicitly defined in the WCAG's main 
> document.
> 
> On the other hand, the Understanding document also says:
> 
> "The author cannot rely on the user agent to satisfy this Success Criterion 
> for HTML content if users do not have access to a user agent with zoom 
> support. For example, if they work in an environment that requires them to 
> use IE 6 or Firefox."
> 
> This may suggest that, for a *global* scenario (where we cannot guarantee 
> what UA is used), using absolute units for text size can be considered a 
> failure of SC 1.4.4. But then it would be very easy for the WAI WG to 
> include a Common Failure in the Techniques document saying that absolute 
> units are not valid.
> 
> I've alwayd interpreted that the absence of such faikure in WCAG 2.0 means 
> that absolute units are not strictly prohibited, unless they cause 
> overlapping/hidden content (F69, for example).
> 
> My concern is that, if I consider the Understanding as an "informative only" 
> document, then the 200% is still subject to interpretation; but if I 
> consider the 200% definition in the Understanding as *the* -mandatory- 
> definition, then the absolute units shoukd also be considered as a direct 
> failure.
> 
> What do you think?
> 
> Regards,
> Ramón.
> 
> 
> Felix wrote:
> 
>> One need only raise the size of a 16px font to about 22.4px to get a 
>> doubling of size. A doubling of a CSS "size" produces an nominal _size_ 
>> increase of 400%.
> 
>

Received on Sunday, 30 October 2011 18:44:46 UTC