W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2004

Re: Using em or percent for properties that need to change

From: Andy Budd <andy@message.uk.com>
Date: Wed, 18 Aug 2004 10:57:41 +0100
Message-Id: <0B7AD796-F0FD-11D8-888E-003065480AC6@message.uk.com>
To: W <w3c-wai-ig@w3.org>

Hi Patrick,

Patrick H. Lauke wrote:

>> Personally I see accessibility being about accessing the content, not 
>> customising it in any way you personally see fit.
>
> But what if the visitors *need* to customise the presentation as 
> otherwise
> it doesn't make an ounce of sense to them? We're not just talking about
> designers who prefer their layouts elastic or fixed...

No, I agree that a certain level of customisation is necessary. However 
I'd question how much of this is the job of the web site developer, the 
browser developer, the OS developer or the developer of assistive 
technologies.

>> Pretty much all the arguments I've heard so far are based on peoples 
>> personal 'preferences'.
>
> To be a bit more trite: users with disabilities are people, and they 
> have
> their preferences as well.

What I'm saying, is that the arguments people are coming up with seem 
to be based more on their personal views than on any hard and fast 
data. It's all very well saying "I think people with low vision would 
want layouts to increase when they increase their font sizes", but 
unless this is backed up with some hard evidence, this is just a 
personal belief (opinion. preference, whatever).

This goes back to my other question about how these guidelines have 
been derived. Is it from people such as yourself giving an expert 
opinion or is it actually from running large scale accessibility test 
on real users and seeing how they actually use the technologies!

>> Sure it's a nice idea that layouts expand if the text is expanded. 
>> It's true that when lines of text get very short they can get more 
>> difficult to read.
>> However, is this an accessibility issue?
>
> Yes, just in the same way that using clear and simple language is an
> accessibility issue
> http://www.w3.org/TR/WCAG10/#gl-facilitate-comprehension
> Looking at the above you may follow the same reasoning about
> "accessibility is the ability to access content", but this obviously 
> goes
> beyond mere "technical accessibility".

I'm afraid that you're missing the point here. CSS allows you to 
separate display from content. Setting a fixed pixel size in the CSS 
can be overridden by the user, by using a user stylesheet for instance. 
If you want, you can even turn stylesheets off. Clear and simple 
language is something that is embedded in the content and cannot be 
changed by the user. As such, there really isn't any similarity between 
the two.


>> Anyway, if a user wishes to up the size of their text, who is to say 
>> that they want the layout to change as well.
>
> And who is to say that they're not? Ideally, they should have the 
> option
> to do both, if they so desire...hence my proposal to implement 
> alternative
> stylesheets to cater for a few select cases.

The functionality built into browsers such as IE clearly indicate that 
you are increasing the text size. From this standpoint it seems 
reasonable to assume that this is what will happen. Some browser 
manufacturers have taken a different approach and actually allow users 
to zoom the whole page.

Surely from a usability standpoint we should respect the browser 
manufacturers intentions and not mess with the expected behaviour?

>> It sounds to me that you are just imposing your own personal 
>> preferences on the user, without thinking about their wishes.
>
> The same happens if you set the size to fixed and *their* wishes were 
> for
> the layout to be elastic.

But we don't know (and can't know) what the user *wishes*. It's 
impossible to design for every possible eventuality.

Like I've said previously (but everybody seems to have conveniently 
ignored), using em's to set width can have their own accessibility 
issues, like forcing the layout to be wider then the viewport. I could 
see that there would be instances where people with tunnel vision 
wouldn't want their layouts to expand when they increase their text 
sizes. Some people with low vision will bump up their text size and 
then sit very close to the screen. In this case short line lengths are 
much easier to read then long ones!

So I find it difficult to understand an accessibility guideline that, 
for some people, could make a site less accessible!

> At the end of the day, it comes down to this (Derek already mentioned 
> this,
> but I'll be a bit more blunt): nobody is forcing you to make your site 
> AAA.
> If you feel that some of the guidelines (or the generally held 
> interpretation
> of said guidelines) are wrong or misguided, don't claim it - or claim 
> AAA and
> have an explanation/rationale for why you feel the site is AAA even 
> though
> some interpretations of the guidelines might say otherwise.


The WAI asked for feedback on the new draft, and this is my feedback. I 
believe that the CSS techniques in question are too vague to be helpful 
to the majority of web designers out there, and need some 
clarification. I also believe that, while increasing a sites 
accessibility in some areas, using these techniques could cause new 
accessibility issues. As such I think it's a valid forum to highlight 
these issues.

I have no interest in claiming AAA compliance. My interest is in seeing 
guidelines that are clear and easy for web developers to interpret.

My interest is also in creating accessible sites. I'd be happier 
building a site that hits all the requirements bar this one (although 
looking at the new guidelines this doesn't actually seem to be a 
requirement, for compliance!) and thus create a site that is highly 
accessible but technically only A rated, than creating a site that gets 
a AA but is actually less accessible.

However, I digress!


Andy Budd

http://www.message.uk.com/
Received on Wednesday, 18 August 2004 09:57:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:44 UTC