Text Resize: A Discussion

Accoeding to my experiences resizing of a whole web page shall be possible with modifying only the font-size entry for the body tag. If the user modify the the default user agent font-size or use a simple user style which set the wanted default font size to an appropriate value the results will be the same as for zooming where the user style sheet has the advantage that any zoom factor can be set. There are no difference for the rendering,
An other big advantage is that browsers which are not really browser (MSIE) will work well.

A disadvantage is of course that some pages are wrong regarding accessibility, font-size and or width/height
expressed in px or other absolute units and no respect of the user agent setting. A good site shall render large textes with the browser default and not decrease/increase this value. This must be a standard and if all site
designer respect this web sites will be more accessible for every person.

Accoeding to my experiences resizing of a whole web page shall be possible with modifying only the font-size entry for the body tag. If the user modify the the default user agent font-size or use a simple user style which set the wanted default font size to an appropriate value the results will be the same as for zooming where the user style sheet has the advantage that any zoom factor can be set. There are no difference for the rendering,
An other big advantage is that browsers which are not really browser (MSIE) will work well.

A disadvantage is of course that some pages are wrong regarding accessibility, font-size and or width/height
expressed in px or other absolute units and no respect of the user agent setting. A good site shall render large textes with the browser default and not decrease/increase this value. This must be a standard and if all site
designer respect this web sites will be more accessible for every person.

@Kevee, you're right. Text resize widgets are completely unnecessary with properly coded and styled pages. I really like @mgifford's approach on his website, where he shows people who want to resize text how to do it within their browser. Of course, not much beats Control-+ on a Windows machine or Command-+ on a Mac.

And just a few months ago, I saw a demo of a tool called Zone Clipper that further reduces the need for these text resize widgets. Two of its features show why text resize is often not helpful to people with low moderate vision:

• It increases the size of the body text, but not necessarily the headings. In fact, in some cases it decreases the size of headings. Headings are shorter than the body of a document, so it takes only a little work for people with low moderate vision to read them when the font size is not extremely large. Think about it: if a person needs 32 point type, then blowing an 8 point page up by a factor of four makes it legible. But at the same time the text went from 8 points to 32, the headings, which started out at, say, 16, would blow up to 64 points. Nobody needs headings to be that big. In fact, text that is so big can be even more difficult to read. So headings need to be big enough to make them out, but no bigger.
• Zone Clipper resizes the text without expanding the column width beyond the edge of the screen. So the person with low moderate vision can read easily and scroll in only one direction — vertically. This dramatically improves the ability to read the text faster.
• Zone Clipper also gives the user complete control over text and background colors. That's important because many people with low moderate vision are more comfortable reading large text with low contrast. The right settings vary wildly with the individual, so Zone Clipper leaves this feature completely in the user's control.

Developed by Wayne Dick, who himself has low moderate vision, Zone Clipper allows a person to select the block of text they want to read from a Web page. They paste that block into Zone Clipper, and it reformats the text to suit their needs.

Offering the resize widgets is considerate, and they were useful just a year or two ago, but they're just not the best answer any more. It's better to point people to solutions that give them greater control.

I posted a question on twitter and got a great response - @webaxe summarized the discussion very well.

I posted a link with "AAA Text Size?" on pages on my site that link to a page educating people about how to use their browser to effectively resize their text.

This might be the best compromise until this functionality is well understood. Someone suggested linking it to an accessibility statement that includes this description, which would work too.

So perhaps in light of this, and another great WebAxe post on the subject recently, we should suggest removing text size widget modules from that previous post with a list of modules/themes which help with accessibility.

That is assuming that we put in a link to the post so that folks know the background.

I prefer methods that are easiest for all users to understand and use. Notwithstanding the downsides to text resizing widgets, I would argue that for some users they are still easier to understand and use than to read through a page of documentation explaining how to resize text from the user agent. WCAG requires that text be resizable to 200% without the use of assistive tech.

Do users even know which browser they are using in order to follow the correct set of text resizing directions? I know some that certainly would not.

There are some pages which contain text resize widgets, they have all limitations.

For my own I think that large textes must be printed out with the default font size of the browser which can be easely set by the user (an other alternative is user style sheets but they are to complicated for most people).

All dimensions must also be expressed in % or em. If this is the case changing the default font size act as the zoom function provided by modern browser with the advantage that this will alway work if the page designer don't use smaller font size as the browser default and if there are not mm, cm, inch, pt and px within the css files and the pages themselve.

@Cliff

I am flying under the radar currently.

Does this method work with IE6 /XP< what about older versions of Safari on older versions of OS X or older versions of Firefox / Opera? I'm not saying that it is impossible, but we are living, as always, in a technology growing pains time, where we need to give consideration to users of older technologies. We also need to consider users so accustomed to instructions being useless that they would never click for them or read them if they found them.

Arguments about anyone being able to use the newest NVDA / Firefox for free are moot.

Thanks

I think that one thing that is useful about the list is that it lets people know every module that claims to help with accessibility, one way or another. I would find it helpful to have that full list broken down into groups.

Yes, this would be a great help! I always assumed an AAA widget was something I should be using.

I've long had a passing interest in a11y, but truthfully have not taken the time to gain more than a superficial understanding. I created that list in preparation for my Drupal podcast, when next month's topic will be accessibility. I'm so glad people with more knowledge are weighing in!

If anyone can point me toward accessibility resources or is willing to critique a pre-release of the show, please contact me.

Thanks!

-NP

I also added a caption to each table, but isn't the styling for captions pathetic (as in absent)? Can we do better?

I also added a brief explanation as to why the text resizers are deprecated. In that explanation, I linked to this discussion and the WebAxe article.

I disagree with the fact that these modules are deprecated. Obviously, since I maintain the Text Resize module. Just saying that obviously all users know how to press Command +/- or Control +/- to increase/decrease font size is just completely untrue. Many elderly users are not as tech-savvy as we younger users and need an easy way to increase the font size on the page. I also find it faulty logic to mark the Text Resize on the wiki page as a deprecated module when the usage statistics of the module are higher than 7 of the 10 modules that are listed in the "Helpful" section at the top of the page. The usage statistics mean that the community disagrees with you and that this is still a helpful tool to have on a site that needs to provide information to a variety of user groups.

I never said that usage statistics measure usefulness. I said that the community disagrees with you that having this type of functionality as part of the interface of a website is deprecated. Yes, while it's true that you might be able to convince your tech-familiar coworkers or your blog readers to use the Control +/- keystrokes pretty quickly, it's going to take the average user much longer to catch up. This type of public awareness doesn't happen over night when a new browser version is released. As mgifford pointed out, many computer users aren't even aware of keystrokes that have been around for ages such as Control+C or Control+V.

In my opinion, marking text resize modules as deprecated at this point in time is misinformation.

@Mark wrote:

"I disagree with the fact that these modules are deprecated. Obviously, since I maintain the Text Resize module. Just saying that obviously all users know how to press Command +/- or Control +/- to increase/decrease font size is just completely untrue. Many elderly users are not as tech-savvy as we younger users and need an easy way to increase the font size on the page. "

• Agreed. I don't want to be educated, I want easy access to your content. I don't want to read a page of documentation about how to make your content accessible to me. I want links that are right there for me to click. "I'm having trouble reading this. Oh look, a thingy I can click on... (click, click) Oh look, I can read without a problem now!".

So, although I appreciate the comments from Mike and Cliff, and from the WebAIM article, at this time I would tend to lean toward text resizing widgets being a good practice. That being said, if your site is part of an Intranet at a software design company, where you can reasonably anticipate all of your users having access to the knowledge of how to resize text in a browser, then I would imagine it to be clutter.

"I also find it faulty logic to mark the Text Resize on the wiki page
as a deprecated module when the usage statistics of the module are higher than 7 of the 10 modules that are listed in the "Helpful" section at the top of the page. The usage statistics mean that the community disagrees with you and that this is still a helpful tool to have on a site that needs to provide information to a variety of user groups."

• I believe that using usage statistics is a great way to find out, roughly speaking, how often a module is used. With a topic as commonly misunderstood as accessibility I don't believe that it tells us much more. I would still suggest that it be modified to "disputed" with a link to this discussion.

I don't want to read a page of documentation about how to make your content accessible to me. I want links that are right there for me to click.

Everett, following Mike's model, you don't have to read a page of documentation. You click a link that looks very much like Mark's link, see a short video that shows you the keystrokes to use to make your browser resize a page, do that yourself, and you're done.

And in that brief time, you've learned how to make every page you encounter on the Web — not just the page you're on — work for you.

I have real data on this. I've taught accessibility techniques twice a week for two years — a total of somewhere around 2000 students. Every one of them has appreciated learning that Control-plus (or Command-plus on a Mac) zooms in on the page and the corresponding combinations with the hyphen or minus zoom out.

Every one.

It's far far better to show people how they can control their environment themselves than to adjust their environment for them.

And, for what it's worth, we aren't really talking about equivalent operations. The text resize widget can adjust the text to any one of three size settings, and it adjusts the size of text only. The browser-based zoom command has a much, much wider range of resizing. Testing it out just now, there are 13 different zoom levels available on this page with FireFox on Mac OS X, and the text and graphics zoom in tandem.

The browser-based zoom is far better, is universal, and is not sufficiently well known. As long as developers add text resize widgets to their sites, people who don't know about their browser's zoom capabilities will continue to remain ignorant. When the norm becomes for developers to do as Mike has done, and show people how to control the zoom level themselves through their browser, then browser-based zooming will become well known among everyone, and especially among people who need it.

So I think "deprecated" is precisely the right word. The time for resize widgets is past. A better solution is available. To best serve people who use our websites, we need to let them know about that better solution — not offer them "support" that they don't actually need.

@Cliff
"I have real data on this. I've taught accessibility techniques twice a week for two years — a total of somewhere around 2000 students. Every one of them has appreciated learning that Control-plus (or Command-plus on a Mac) zooms in on the page and the corresponding combinations with the hyphen or minus"

I note that these are students that are in a class on accessibility (voluntarily or mandated), who are there to learn about accessibility.

I agree completely that the preferred method is that every person learn about the native functionality of their user agent. But, I question if on a web site where I need information * now * is the right place to learn. And, I would argue (not having watched the video) that it would take longer for some to learn than for others. It also requires use of two hands in some cases, requires finding these keys on the keyboard, etc. Or I can just click, click and be done.

As for user agent zoom:

1. I don't like full-page zoom because it makes content go off the right side of my browser window, and I dislike horizontal scrolling.
2. Zooming text makes headlines too big.
3. In real life, I use Firefox's feature to set a minimum font size, in my case 18.
4. Safari, at least computer Safari as opposed to iPhone Safari, also lets the customer set a minimum font size.
5. Internet Explorer has an accessibility option to ignore a site's setting of font size.
6. Some of my agency's customers, based on the complaints I get, are not tech-savvy.

So, I still think there is a place for a zoom widget. That it is/would be in Drupal and not in different browsers has the advantage of standardizing it across Drupal websites and across browsers, as well as being able to deal with the heading issue in a consistent manner.

But now to the dirty secret of zooming:

Many websites fall apart if I mess with font size. They overprint or cut off text, probably due to use of absolute positioning. It is not enough for a website to provide a widget or instructions and think they are done. They have to look at what they have put into their design which will break when somebody applies accessibility techniques to the user agent.

The advantage of providing zooming features as a site feature is that the site programmers and designers can test what happens when their tools are used. It is true that they can also test this at the user-agent end, but then there are a lot more variables to test.

For example, I know someone who blows up text so large that he reads one or two words per line. Wouldn't it be great if all he has to do is scroll down? Providing a control on the Drupal website would allow this to be accomplished in a manner the website has control over.

for what it is worth, here is my recently-devalued 2 U.S. cents' worth on the drupal text re-size module:

1. providing links to dynamically change the font size or other font properties is an "until user agent..." technique -- browsers now provide that functionality -- to let users continue to use their tools without learning about features such as zoom, is a decided disservice to users, who then do not have the knowledge to adjust the font on pages that don't offer a font changing mechanism/module, despite the fact that they have the ability to do so at their fingertips/voice-command

2. providing a text resizing module is less efficient than native zoom, as zoom magnifies everything, not just the text

3. providing a text resizing module isn't a bad thing, it obviously helps some users, but one of the main thrusts of accessiblity is to make accessibility features more ubiquitous, and sometimes, that entails education -- therefore, one should use the text resize module responsibly, which -- in my opinion -- is precisely what mgifford has done at the site he referenced

4. i would give good odds that many of those whom cliff has taught web accessibility didn't know about common keyboard commands because they always use a mouse/pointing device to achieve routine results -- a user who can click on the status bar icon to change font size doesn't need to know about the keyboard commands, but in my experience of training sighted as well as blind users, having multiple means of achieving a desired result is always appreciated by the user, no matter what the level of visual acuity...

I just spotted these W3C WAI recommendations, which interestingly only mention zoom and not text size adjustment

http://www.w3.org/WAI/users/browsing#seeing

We've just hit the same issue with the Maavis project which proves simple zoom controls but this leads to horizontal scrolling and sometimes missed areas. I've also seen many sites that break when text size is changed. So we've not found the perfect solution yet.