E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Wolf, Jan
Date: Tue, Aug 12 2008 11:30AM
Subject: WCAG 2 and browser ZOOM and font units
No previous message | Next message →

With WCAG 2 and Section 508 being updated to provide for technical
advances, how do people view the ability to ZOOM in FireFox 3 and IE7 as
it applies to font size units? Does this negate the need to use
resizeable fonts? I would prefer to use resizeable fonts BUT it does
require more thought and talent to produce a layout that retains its
usability/readability when fonts are resized in a browser. With the
newest browsers allowing a user to ZOOM in, I have a hard time making
the case to our programmers that they should continue to use resizeable
fonts. I don't even know if I can truly say that WCAG 2 will require it.


Opinions please?

From: Moore, Michael
Date: Tue, Aug 12 2008 12:40PM
Subject: Re: WCAG 2 and browser ZOOM and font units
← Previous message | Next message →

Jan Wolf wrote:

With WCAG 2 and Section 508 being updated to provide for technical
advances, how do people view the ability to ZOOM in FireFox 3 and IE7 as
it applies to font size units? Does this negate the need to use
resizeable fonts? I would prefer to use resizeable fonts BUT it does
require more thought and talent to produce a layout that retains its
usability/readability when fonts are resized in a browser. With the
newest browsers allowing a user to ZOOM in, I have a hard time making
the case to our programmers that they should continue to use resizeable
fonts. I don't even know if I can truly say that WCAG 2 will require it.


Opinions please?

My opinion:

Keep using scalable fonts.

1. Internet Explorer and Opera scale everything with the Zoom feature, a
quick test with IE 7 revealed that zooming the browser does not result
in reflow on a site designed with relative units for the container divs
(a page with a fluid design that should reflow). This results in the
need to scroll left to right. Increasing just the text size on the same
site works fine.
2. Fixed font sizes are frequently coupled with fixed units for other
aspects of the design resulting in poor, or no reflow which can be a
major impediment for people using screen magnifiers. For example, people
using screen magnifiers must pan around a browser window, if they must
also pan to the bottom of the window to use the left to right scroll bar
to view the page this creates additional usability problems.
3. I like to consider fixed font sizes in the same light as other items
that may be less important with newer technologies. One example is
Window Eyes and JAWS have both become quite good at guessing labels for
form fields with printed labels even when they are not programmatically
defined. This would never imply that it would be ok to leave off form
field label elements that are programmatically bound to the inputs.
People may be using older technologies, design changes could lead to
unexpected results, and changes to browsers or assistive technologies
could also result in adverse effects.

Mike

From: Steve Green
Date: Tue, Aug 12 2008 1:00PM
Subject: Re: WCAG 2 and browser ZOOM and font units
← Previous message | Next message →

From: Alastair Campbell
Date: Wed, Aug 13 2008 5:00AM
Subject: Re: WCAG 2 and browser ZOOM and font units
← Previous message | Next message →

WCAG 2 basically requires testing of the site at upto 200% text size,
without specifying the method, so presumably is based on current
usage.

Currently, whilst there are still significant IE6 users, this has to
include by the text size method. Perhaps when IE6 goes the way of NN4
it might be different.

I say might, because the different browsers use different algorithms
(Opera itself includes 2 versions of zoom), and Firefox users can
still use the text method. Also, a lot of corporates and universities
are likely to stick with IE6 for a while, so it may not be as soon as
you think.

Most of the zoom methods do overcome the fixed font + fixed height
issues, but can also create other problems like horizontal scrolling.

The best methods seem to be moving to a more test-oriented method, and
it might take a while for some best-practices to surface. I think that
bullet-proofed layouts that flex within max/min limits seem to work
quite well across the most situations (which is what we've favoured
thus far). Second to that, fixed width layouts with height
bullet-proofing would be my next choice in layout.

-Alastair

From: Sofia Celic
Date: Wed, Aug 13 2008 7:50AM
Subject: Re: WCAG 2 and browser ZOOM and font units
← Previous message | Next message →

The zoom functionality is sufficient to meet the current version of WCAG 2
at level AA if the following are met:
- the target user agent environment has access to user agents with zoom
functionality
- the content does not "break" when zoom is used.

The zoom functionality is sufficient to meet the current version of WCAG 2
at level AAA if the content does not require horizontal scrolling to read a
line of text on standard desktop/laptop displays in a maximized window (in
addition to level AA requirements). However, this is covered by a success
criterion that is currently at risk and is thus subject to change.

From: Wolf, Jan
Date: Wed, Aug 13 2008 8:10AM
Subject: Re: WCAG 2 and browser ZOOM and font units
← Previous message | Next message →

Thanks everybody who got back to me with their opinions. And thanks
Alastair, your opinion answers my question in relationship to WCAG 2.
Not sure how I missed the "up to 200% text size" in the WCAG 2 but that
is good to know. Then of course the issue with that criterion is how do
we test? Text resize or Zoom? And you answered that question in that
currently both options are available and probably will be for the near
future.

My dilemma for much of web design/development is finding that balance
between reality and compliance (standards and accessibility). The
reality of the situation is that we have business managers who want
complex layouts that require skilled designers and resources to test in
order to get truly accessible, as you put it, "bullet-proof layouts that
flex within max/min limits". Yet my agency requires and hires
programmers to design using .NET without any skill level requirement for
CSS or standard compliant coding or for that matter accessibility. Thus,
the abilities are varied and limited.

The reality of the situation is that management won't "settle" for a
truly accessible design that is within the capabilities of the developer
and tool combination. Instead, they feel it's an acceptable business
decision to use fixed width layouts and fixed font sizes to get a look
that can't be achieved otherwise, given the tools, skill levels and
project timeframes.

Slowly but surely accessibility and standards compliant coding is
getting management's attention but it will probably be a while before
their mindset changes enough where they look to hire standards compliant
accessibility-aware developers. It will probably be a while before they
actually provide and require formalized training to get and keep the
developers up to speed as technology and standards change. And it might
be never when they actually demand that auto-generated code be standards
compliant and accessible by default, without all kinds of gyrations,
knowledge and skill.

Thanks for the help and I will convey the font-size issues as they
pertain to WCAG 2 knowing that your second method of fixed widths with
height and resizeable text will likely be their most attainable solution
at this time.

From: Austin, Darrel
Date: Thu, Aug 14 2008 12:00PM
Subject: Re: WCAG 2 and browser ZOOM and font units
← Previous message | Next message →

> I have a hard time making
> the case to our programmers that they should continue to use
resizeable
> fonts.

As developers, they have absolutely no idea:

a) what the end-user's browser viewport size it
b) what their OS font size settings/preferences are
c) what their web browser font size settings are
d) what fonts they have installed
e) if they use user-CSS

So, the zoom really has nothing to do with it. If they aren't
accommodating variable font sizes, then they aren't designing good web
UIs to begin with.

It's not HARDER to accommodate variable font sizing, it's just DIFFERENT
compared to traditional desktop application UI design.

-Darrel

From: Austin, Darrel
Date: Thu, Aug 14 2008 12:10PM
Subject: Re: WCAG 2 and browser ZOOM and font units
← Previous message | Next message →

> Yet my agency requires and hires
> programmers to design using .NET without any skill level requirement
> for
> CSS or standard compliant coding or for that matter accessibility.

This is partly MS's fault, as--especially with asp.net 1.1--there wasn't
much in the way that required developers to even grasp what CSS and
valid HTML and the like was.

A lot of .net developers are folks that were VB or Windows App
developers. ASP.net came along and MS gave them an IDE that pretty much
looked like things were done back in the days of writing windows apps:
drag and drop grid layout (ie, absolute positioning), style properties
(ie, CSS, or even worse, FONT tags), datagrids (ie, HTML tables), etc.
Most every standard HTML/CSS element was renamed into some more 'windows
apps friendly' term that basically allowed developers to not have to
figure out the web at that point.

And to compound the issue, a lot of the built in asp.net controls in the
1.1 framework would then generate really ugly HTML.

The ASP.net framework upgrades (2, 3+, etc.) have improved quite a bit,
but I think there's a lot of bad habit hold-over from the earlier
transition to .net.

Of course, none of that helps you in any way other than me saying I
empathize and wish you luck! ;o)

-Darrel

From: Wolf, Jan
Date: Thu, Aug 14 2008 1:00PM
Subject: Re: WCAG 2 and browser ZOOM and font units
← Previous message | No next message

Darrel said -
> The ASP.net framework upgrades (2, 3+, etc.) have improved quite a
bit, but I think there's a lot of bad habit hold-over from the earlier
transition to .net.
> Of course, none of that helps you in any way other than me saying I
empathize and wish you luck! ;o)

Yep, first there is the need to understand the issues (what is good
accessible code?) and then how to get the tool to produce that good
accessible code.

There is this big brick wall that I beat my head against, the graffiti
on it says "Business as usual" :(

BTW, Empathy and a wish for luck is very nice :)

Thanks!!