Big, Stark & Chunky

by
Published in Accessibility, Browsers, CSS, Graphic Design, Layout & Grids, Typography & Web Fonts

Readers of A List Apart will by now be quite familiar with screen-reader users, the largest group of disabled web surfers whom standards compliance actually helps. In a previous article, for example, I examined how well image-replacement techniques work in screen readers (not very).

Article Continues Below
Article Continues Below

But — surprise! — most people with impaired vision can still see something, and a large but unquantified segment of this group sees well enough to use a computer with a magnified or zoomed display. We have not done a good job of catering to these screen-magnification or zoom users. Using CSS, it’s easy to do, as we shall soon see. And moreover, using CSS to develop zoom layouts is almost exactly what developers of handheld and PDA browsers are doing in their quest for small-screen rendering of wide, multicolumn web pages.

But first, let’s understand the problem.

A different way to view the web#section2

Websites are mostly type. A low-vision person will probably be able to read type on a web page if it’s big enough and if it’s presented in a certain color scheme.

But when you blow up the fonts on a web page, eventually your display runs out of room. Or even if it doesn’t (are you using a 50-inch plasma display? how about two 30-inch Cinema Displays?), you the low-vision user are sitting at a certain distance from the screen, giving you only a limited field of comfortable view. Moreover, your vision loss may involve visual field; you may simply see less than people with normal vision or even people with other visual impairments.

Eventually, then, every website will outgrow its container if you zoom in far enough. The container may be table cells, divs, the monitor, or the user’s visual field, or any combination. You can use CSS to make sure your site does not knowingly zoom past the perimeter of a user’s vision.

Research#section3

There’s a modicum of published research documenting the needs of zoom users. Of most recent interest is a paper by Ginny Redish and Mary Theofanos (see references).

While many participants in their study had trouble when color was removed from a web page (as some screen magnifiers do when they switch to high contrast), the biggest problem was multicolumn page designs. A few users never discovered some of the columns. Some components, even when located inside a single column that subjects could theoretically see and use, had already scrolled right off the screen and were ignored.

Some highlights from that paper:

  • These users, however, do not want a “different” site: They don’t want a “screen-magnifier version” or a “text version” if that means a site that has to be separately maintained from the main version. They believe the sites would not be equivalent. They believe the “special” site would not be kept up-to-date.  The issue is how to provide “experience equity” and universal usable access to all low-vision users.
  • [One participant stated] “Headings and bold are very important.”
  • [Participants] told us that they often copied and pasted material into Word where they could enlarge the font even more and make it bold, thus rendering it easier for them to see.  Two other participants made conscious decisions about viewing strategies to accommodate the problems caused by wanting to maximize both how much of the page you see and how easily you can read it. [One person] kept the magnification at 2×, which he said was lower than he needed; he said he was sacrificing ease of reading for seeing more on the screen. 
  • Most of our participants did not use cursor control keys even when doing so might have helped them. Instead, they moused around the screen very rapidly, and, in doing so, often lost any sense of where they were on the web page.
  • Users who do not work with the scroll bar may never go to the right side of the screen.
  • Users can miss items – even ones that are next to each other – when the screen is magnified.

Destroy your own design#section4

Now, standardistas have spent years coming up with multicolumn page designs that look nice, render more or less the same in compliant browsers, and (for the keener developers) are also usable to screen readers. We took a slightly defective model (multicolumn pages laid out with tag-soup tables) and cleaned it up somewhat (multicolumn pages laid out with valid HTML and CSS).

Standardistas were able to stomach the idea that blind people were simply ignoring the appearance of their sites because, self-evidently, they were blind. It was no big deal; nothing happens to your visual design when you accommodate blind people.

But to accommodate low-vision people, you have to totally rearrange your multicolumn site. You have to knowingly destroy your original graphic design. But do we need to throw out the baby with the bathwater? No. You can use CSS to customize all versions of your site.

  • Your default page can use whatever graphic design you like.
  • Through a site-preferences page or a simple style sheet switcher, the user can switch the same information to a single-column view with big fonts. You can tweak which portions of your navigation scheme actually appear, and where, in each design; you generally want less navigation.
  • Since we’re not making a text-only page that would probably end up neglected, but are merely providing a different view of the same page, we obviate low-vision users’ fears of being stuck in special gulag.

Design basics#section5

Your low-vision design should do the following:

Switch to a big font
You can let the visitor enter a point size by keyboard, or you can give a reasonable set of predetermined options. Unless you’re using something truly weird (Zapf Chancery, anyone?), you don’t have to worry about font selection. Keep your line-height proportional.
Invert the screen

 

Many visitors will want light-on-dark text rather than the dark-on-light text we’ve gotten used to since the first Macintosh.
Customize colors
However, bright white on flat black will not work for everyone; it’s too bright. You can provide a few options, many of them reminiscent of 1980s-era terminals (e.g., green, yellow, or blue on black or dark brown, or the old WordPerfect 5.1 default of white on blue).
Rearrange content
This is the biggie: You have to judiciously prune your multicolumn site into one column.

If you want to be really fancy, you can make each of these options individually selectable; you might use a preferences page that lets visitors selectively enable options. (That page would pretty much have to include all the above features at once to be accessible in the first place.) But if you’re just starting out, clustering all these options as a one-click option through a single CSS file will suffice.

And a note about images: Don’t do anything special to them. Do not, above all, assume that a low-vision person won’t be interested in your photos or illustrations. We already know that low-vision kids love digicams and love shooting pictures, since the photos can then be blown up nice and big and edited on computer. If your site features thumbnails or galleries that take up a lot of horizontal space, you may need to rethink your layout. But for nearly all other sites, don’t try to hide, shrink, or enlarge your images.

Navigation#section6

We know from experience with screen-reader users that too much navigation on a page is a serious usability problem. Why else did we invent, and endlessly debate the details of, the now-infamous skip-navigation link?

Now consider the problem for a zoom user. If your navigation (whether a styled unordered list or whatever else) sits in a column at screen left, either that column will occupy a huge percentage of a magnified screen or the visitor will have horizontally scrolled to eliminate it. A large left-hand nav column is simply in the way.

The real solution is to simplify navigation so that it can be skipped if desired or just read in sequence with minimal inconvenience or confusion. I have to agree with J the Z here: If you think your site needs drop-down menus, you need to streamline your site.

To improve navigation for magnifier users:

  • In most cases, we’ll want one or at most two lines of navbar text — presented horizontally at screen top.
  • If your navigation is already simple, you may merely need to update your CSS.
  • If you’re stuck using a huge chunk of navigation, extract only the most important parts for the top navigation row. The rest can be contained at the bottom of the page, for example.

We do not have mature and well-tested ways to do this; it’s all a bit new. Worse yet, HTML stands in our way to some extent. Our options include:

  • If your navbar is marked up as a single unordered list, it may be necessary to assign classes to the items you wish to show or hide in a zoomed layout (whichever are less numerous, I suppose).
  • Another option is to use two lists, though that presumes that the precise order of entries works out fine (all the entries you want to show in a zoom layout just happen to be consecutive in one list).
  • If you have just a few items that are marked up as regular elements with divider characters between them, your navigation may be simple enough to leave as-is. If not, you can write a second navbar into your code and selectively show and hide the right navbar in different CSS files.

Examples#section7

My esteemed colleagues Cameron Adams and Sergio Villareal wrote new zoom-layout CSS files for their sites, which you can take a look at as approximate examples of this rather new form.

Cameron Adams
The Man in Blue
Regular
Zoom layout (“contrast layout,” actually)
Sergio Villareal
Overcaffeinated
Regular
Zoom layout (“high-contrast layout,” actually)
Single-column layout

This is not a lot to go on, but it’s all I could squeeze out of the many developers I polled over a period of five months.

We need further examples of zoom layouts to solidify the whole idea in the minds of visual designers. If you give this a whirl yourself on your own site, let us know in the comments to this article and, preferably, also on the ZoomLayouts page at the CSS-Discuss wiki.

Meanwhile, some existing sites use preference pages to specify type and color:

  1. K.S. Pope
  2. Confort de lecture (an offshoot of Handicapzéro)
  3. Sjoerd Visscher

Media types#section8

So far, I have not been able to achieve consensus among potentates of the CSS Working Group that we need a new media type, zoom, to accommodate screen-magnification users. (By contrast, there was some modest agreement that a new reader property was needed. Though that proposal hasn’t gone anywhere, it still could.)

Given the constellation of display properties involved in zoom layouts, with display and hiding of specific page elements, it may be necessary to contemplate a zoom media type after all. I leave this task to others.

Similarities with small-screen rendering#section9

As it turns out, what you’re doing when you use CSS to design a zoom layout is similar to what a handheld browser must do when confronted by a wide, multicolumn page. It too must selectively reorder and hide components so the page content can be enjoyed in a single column. The difference is that there is no significant need to radically restyle the type to make it easier to read; even the default type presentation on many handhelds is considered readable and doesn’t need to be touched.

We can compare the display formats this way:

Conventional Zoom Handheld
No single assumed audience Low-vision audience (no personal choice) PDA owner (personal choice)
Single- or multicolumn Single-column
No limits on navigation Simple navigation preferred Navigation eliminated, rewritten by proxy server, or deferred to page end
Any type color Light-on-dark preferred Browser defaults (usually dark-on-light) preferred
Any type size Large needed Browser defaults preferred

The more advanced small-screen-rendering (SSR) platforms attempt to intelligently determine which side-by-side components, images, headers, footers, and dividers of many sorts are actually important. With few sites offering valid markup, with fewer still using CSS for layout, and with no consensus at all as to how to name different components of a page, SSR devices face a serious challenge of artificial intelligence. (See references below.)

However, you as designer or developer know your own site and all its conventions. There may be a bit of trial and error in CSS properties until you produce a zoom layout that’s simple, big, and readable, but you know up front that it’s possible. And in fact, you can reuse some of the knowledge you gain in rewriting your site for zoomability to make it compatible with handhelds. Starting with your new zoomable style, make the following changes:

  1. Retain a single-column layout.
  2. Don’t specify font, size, or color (unless you really know the platforms your visitors use).
  3. Consider hiding or at least moving all your navigation. Put the content of the page first.
  4. Continue to refrain from doing anything special to images. They are a known issue in PDA browser software and you should let these user agents handle images themselves.

Conclusion#section10

This article will, one hopes, serve as a starting point for a new application of CSS design principles by standards-compliant designers. It seems that, as time goes on, we discover more and more implementation details of what appear on the surface to be technologies that are frozen in time (viz. the HTML and CSS specifications). Similarly, with each passing year we learn more about how to accommodate people with disabilities gracefully without impeding the graphic design or other desirable characteristics of our sites.

But the ball is now in your court. I’d like to see quite a few more attempts at zoom layouts and, in the fullness of time, a general consensus that a professionally-designed, standards-compliant, accessible site isn’t complete without one.

References#section11

Low-vision users#section12

Helping low-vision and other users with websites that meet their needs: Is one site for all feasible? (Redish and Theofanos)
High Accessibility, High Design

Small-screen rendering#section13

Collapse-to-Zoom: Viewing Web Pages on Small-Screen Devices by Interactively Removing Irrelevant Content

The marquee-menu methods explored in this paper — in which PDA users draw diagonal lines to collapse and expand page components — could easily be expanded to conventional browsers, as through a Firefox or Mozilla extension. (It could also be built in as standard equipment. Doing so would, incidentally, assist but not ensure compliance with Guideline 5  of the User Agent Accessibility Guidelines.)

href=“http://www2003.org/cdrom/papers/refereed/p297/p297-chen.htm”
id=“Detecting-a” title=“Full text
online”>Detecting Web-Page Structure for Adaptive
Viewing on Small-Form-Factor Devices
The authors’ method here attempts to infer structure from HTML so it can reorder page components. Needless to say, the whole thing breaks down with invalid markup: “In the page-analysis stage, HTML syntax errors left by the author could cause the HTML parser to produce [an] erroneous HTML DOM tree, which could sometimes make the high-level content-block detection produce unexpected results. For example, a pair of misplaced <form> and </form> [tags] in a web page causes our parser to place the footer of the web page under a small table in the body.”
href=“http://research.microsoft.com/research/pubs/view.aspx?tr_id=625”
id=“SmartView-R” title=“Microsoft Research
page”>SmartView: Enhanced Document Viewer for
Mobile Devices
  • PDF (which Google refuses to index since it’s on an FTP site)

“Currently, far too little published material on the web is suitable for mobile devices [undesirable anyway from the standpoint of device-independence]…. In a few well-defined cases, the SmartView prototype even adjusts the layout of a section by breaking it up completely and re-flowing it to fit in the window…. The layout is modified by changing the side-by-side arrangements into a top-down arrangement, because the latter is more effective on small screens.”

Opera’s Small-Screen Rendering

Acknowledgement#section14

Many of the methods described in this article are derived from apresentation by Aries Arditi at the American Academy of Optometry convention, Dallas, 2003.12.06. The author contacted Mr. Arditi for a reference or citation to that presentation, but received no response.

49 Reader Comments

  2. I have tried to create a fluid design for my website. I think with that I have covered the font size issue.

    This article have open my eyes regarding excessive use of navigation aid and complex multicolumn designs.

  3. We’re getting to the point where the blind and vision-impaired have it better than the seeing. I think we need to concentrate more on DOM programming that enhances navigation, brilliant little Perl pouches, and creative new ways to trick the blind (possibly “next page” buttons that are secretly “buy it now”). And yes, I realize where I’m going after I die. Same place you are.

  4. When and why did the skip navigation link become infamous? I find it very useful when surfing with a handheld…

  6. it’s funny. I always thought that low vision users would like the black on white. Since white on black would be optimal and is the case… what colors are we supposed to make links? Do we just make them the same but with underlines?

    Anyway, good article. I am currently using an “undesigned look” at DustinDiaz.com for the low grade ‘easier-to-read’ layout. But after reading this article, I think I might add an extra style sheet to change the contrast settings to white on black.

  7. Great article, Joe. It got me moving. One thing hit me right away when I started designing the high contrast portion of the style sheet: What’s the best way to differentiate link color (e.g. in a white-on-black configuration)?

    Did a cursory look-around for some research that hit on this, but didn’t see anything right away. What would you recommend?

  8. funny thing about the second example…
    I couldn’t find the style switcher. The first one was easy (right at the top)….

    which brings me to ask the question, “Where are we supposed to put our style switcher links?”

    for someone who has supposive low vision, wouldn’t we want to make the “go to impared vision layout” link quite big with lots of contrast? I mean, I know none of us want to break our beautiful layouts that have a 10 pixel type-face with 18px line-height.

    I think part of this article assumes that you don’t need to risk any design changes to your current layout, but if your ‘go-to’ button isn’t easily accessible, you might as well not have a separate zoom layout. Don’t get me wrong, still an excellent article with plenty wisdom, especially on teaching the mechanics of developing the zoom layout itself and some extra knowledge about visually impared users that I never knew before.

    I just think that designers are eventually going to have to budge a little more than they wanted to.

  10. 1. IE6 has a ‘zoom’ filter. It can enlarge the entire page elements, including fonts set in pixels (honest!), images and scrollbars! Sadly it is buggy and can’t be used out of the box. See my post on this here:

    http://www.designdetector.com/archives/04/07/IECanZoomPagesLikeOpera.php

    2. Opera is surely the answer to anyone with low vision. Like anything else in life, you use the right tool for the job. It allows the entire page to be zoomed, stylesheets to be knocked off completely at the press of a button (handy even for people with good eyesight) and high contrast stylesheets to be added, again just via a button. These include black on white, white on black, an accessibility layout and more. It’s also very easy to add your own custom stylesheets. Plus Opera 8 has SSR (and MSR?) built-in.

    3. Surely the best way to get a single column is to turn off styles? Then everything flows down the page. You can then enlarge the text as you see fit.

    4. The example Zoom layout given by Cameron Adams is messed up in Opera – text overlays text.

    5. “Don’t specify font, size, or color.” – this contradicts what is stated earlier: “Switch to a big font” and “Customize colors”. Unless ‘low vision layout’ is not the same as ‘zoom layout’.

    6. Study the way existing systems like Betsie (the BBC’s low vision website parser) work. They tend to show the screen black with large yellow and cyan text set in Verdana. (Are sans serif fonts a better choice than serif ones? If so, we need to set the font, as many browsers use Times as the default font for unstyled text.)

    7. Any options (such as styleswitchers or font change menus) would be best put in the top left corner. That way they can’t be zoomed out of view.

  11. As “zoom enabled” layouts seem to be less complex then their counterpart, it makes one wonder whether it would be a lot simpler to start out with a zoom enabled layout and add in additional detail, columns etc afterwards, instead of working the other way round.

    This streamlining process would benefit navigation and usability issues, creating an incremental development cycle?

    Any suggestions?

  13. Using the available zoom functions on Opera and IE (yes it really can work) or creating CSS that zooms with font size as linked to by Caspar are all well and good for a small amount of zooming.

    But one of the point in the article is that this is no good for people who need quite a lot of zoom if you go above too much, wham all the content shoots off the right side of the browser. We all know that left-right scrolling is annoying but imagine having to to back and forth for each line.

    No I fear that these methods are not the answer here.

    Chris Hester also says that the best way to get a single column is to switch off CSS, again I fear this is a quick fix, this does not address the issue of contrast which is important here.

    Incidentally great article Joe!

  14. Since specifying column width in em’s will end up in horizontal scroll bar after setting big font sizes. So back to percentages or pixel width?

  16. Depending on the type of visual disability, forcing the user to reverse contrast can make the readability worse. Low vision users with Albinism, for example, prefer the common white background with dark type. As Joe said, there are many types of visual disabilities. The idea that all low vision users like a reverse contrast is a dis-service.

    Excellent article on single column and simplified navigation. I will try it out this weekend. I have been meaning to put in a CSS stylesheet switcher for zoom text. This is good motivation.

    Thanks!

  18. Great article that clearly outlines many of the common misconceptions and design mistakes that disadvantage users with disabilities. I usually, however, tend to find myself in the ‘user preferences are for sissies’ camp – http://www.yourtotalsite.com/archives/usability/user_preferences_are_for_/Default.aspx.

    User agents for enlarging page content (from ZoomText to Opera to IE) tend to perform nearly all of the functionality described here whether through simple font enlarging or (selective or complete) style switching. The only exception is the removal of multi-column layouts, though even most of these COULD be designed to allow fairly significant scaling.

    Why place the onus of implementing style switching, creating multi-display designs, and determining specific ‘accessible’ styles (even experts can decide on these) on site developers when the end user can and should be able to customize these natively without the additional burden of discovering and using user preferences?

    In short, if your design is one that requires user preferences, then you’ve PROBABLY messed something up or are too chicken to make a solid design decision in the first place.

  19. “The idea that all low vision users like a reverse contrast is a dis-service.”

    Oh c’mon. Next thing you know, you’ll be trying to tell us that all brown eyed men don’t love fried banana sandwiches. 😉

    Usability is a very very complex issue. No single article can cover all the angles, not even of such a narrow area as vision impaired users. I think anything that gets people thinking about it at all is a step in the right direction.

    The way I look at it (and I’d love to see some research that could back me up [or prove me wrong]) is that, if I were vision impared beyond my present state (I keep my font sizes bumped up a couple of notches just to avoid headaches) and ran across a site in the vast and rather unfriendly ocean of the internet which took my needs into account, they’d earn themselves a loyal customer pretty damn quick. And it doesn’t take that much work on our parts. So why not do it?

  20. Was there some research or testing to determine that low vision people are better off with light text on a dark background? It seems counter-intuitive.

    I hate light on dark and if I take my glasses off I hate it more. I took over a site with light text on a dark background a few years ago and switching to dark on light light has gotten me more complments than any other change I made.

  21. Doesn’t this contradict the articles’ “don’t do anything to images”? Personally, I can’t understand why making the image zoom with the text is bad (other than it’s pixelated, but it will get that way whether the designer or the assistive technology does the zooming).

    Can someone please enlighten me on this?

  23. Alot of screen magnifiers are expensive and it seems unfair to penalise people with low vision. So we developed a screen magnification software package called WorksView which is free for the end users. It’s a browser plug-in and is currently being used by various councils and commercial organisations:
    http://www.havant.gov.uk
    http://www.macclesfield.gov.uk
    http://www.kingston.gov.uk
    http://www.casio.co.uk
    http://www.solicitors.co.uk

    We have also developed a zooming tool called WorksEye which is on the Casio website. If anyone’s got any feedback it would be much appreciated.

    thanks
    Huw

  25. Having both modest vision impairment and cognitive impairment, I deeply appreciate Joe’s article and encouraging responses.

    As far as “what do we do with the links?” my preference is: distinguish them semantically, let me choose their display.

    I turn off link underlines, because they reduce readability, and besides, underlining is a typewriter artifact that clashes with real fonts.

    I want all my links to be purple. That way I don’t have to decode each site, “ok, which color is text and which color is link?” My brain is wired so that color-to-function mapping is slow.

    I set these colors in my UA. Don’t over ride them for me or I just have to over ride your design, again.

  29. Circus, the Microsoft/Forrester studies (http://www.microsoft.com/enable/research/default.aspx) may be of use, but it’s all a little convoluted. They say (for US working-age adults):

    Approximately one in four (27%) have a visual difficulty or impairment.

    16% (27.4 million) of working-age adults have a mild visual difficulty or impairment, and 11% (18.5 million) of working-age adults have a severe visual difficulty or impairment.

    That’s a fair amount, but be aware that “mild visual difficulty” will include people for whom glasses/contact lenses are their assistive technology. Having said that, a high proportion of people who already wear glasses do still benefit from other technologies, such as the ability to enlarge/shrink text at will and particularly to reduce glare by changing white backgrounds to a pastel/grey colour (this also applies to many people with specific learning difficulties).

    I welcome Joe’s ideas and the continued education/discussion of more than just screen reader users, but we have to be careful not to make too many assumptions. A fully featured and customizable stylesheet switcher (where you can set various options rather than just between the author’s favourite blue and green themes) is a great idea for loads of your visitors, and it’s entirely redundant and overcomplex given that users who are in the know are aware they can fire up their own user stylesheet and override styling anyway. One of the big disadvantages of site-based stylesheet switchers is that it doesn’t follow you around once you leave; a user defined stylesheet does.
    Web developers and designers determine the content and the presentation that information is *published* in, but it’s the user and their user agent that determine the environment the information is *received* in.

    In an ideal world, where users were able to self-educate (or were interested in the technicalities of the web), and where everything was coded according to standards and the standards were more exciting than what they are, we wouldn’t need any skip navigation links (because page navigation is the job of the user agent, and site navigation sections would be a distinct and identifiable element), nor we would need any stylesheet switchers and so on. We could just publish freely in the knowledge that the standards folks and the user-agent folks were happy and cheery and helpful and dreamy and knew what they were doing, rather than having to hack accessibility into everything.

    Until then, comrades.

  30. I’m experimenting a bit with stylesheets and trying to include the comments made in this discussion. As I gather from what is said:
    – Just add the minimal CSS to turn vertical list navigational elements to a horizontal list
    – Add some borders and/or alignment statements for data that is presented in a table
    – Leave as much possible to the settings of the browser.
    – Reset to a one column layout whenever feasible.

    I wonder though how much visually impaired people actually know how to set their own stylesheets. Changing standard link colours, background colours, foreground colours, fonts and typesizes are elements in the preferences panels of most browsers, but adding your own stylesheet might be a bit too technical.

    Are the standard browser interface settings enough to give the right user experience, or do we need some options to be configurable and written to a stylesheet?

  31. Ironically, the link in your comment isn’t underlined.

    If the link color (for links outside of context) is consistent throughout the site and sufficiently distinct from the normal text color then underlining is not necessary.

  32. “I turn off link underlines, because they reduce readability”

    That’s a slap in the face for accessibility people who advocate all links should be underlined!

    “Shame *what* only works in IE?”

    The WorksView software described in the comment above mine.

  33. TechDis used to have a create-your-own-stylesheet wizard which was fairly simply to use (http://www.techdis.ac.uk/seven/wizards/) but it seems to have fallen by the wayside. The principle was sound though and could be reinvestigated. Of course, it’s all about knowing where to find it, too…

  34. I am not visually impaired yet I found myself using a little favelet to zap pages with black or very dark background all the time. And then I turn up font sizes a few notches.

    Two buttons, ‘change colors’ and ‘change layout’ in the top left corner might be a good solution. One could cycle through a set of color schemes and layout options independently and save it in a cookie.

    Any non-default selection could force all links to be underlined.

  35. I’ve added a stylesheet to my website to give users maximum flexibility in their preferred visuals of the site.

    The site is located at http://www.noipo.org and the stylesheet can be selected through ‘preferences’.

    It’s quite simple, I’ve done nothing but styling the navigational items a bit and leave the rest up to the browser settings.

    Navigation is before content, but since the navigation area is flexible in size I haven’t figured out a way to put it below the content in the mark-up, but above the content using CSS.

  36. I described my personal user agent choices as it relates to my visual abilities and aesthetic preferences.

    “That’s a slap in the face for accessibility people who advocate all links should be underlined!”

    I = me. I >< people who advocate underlined links. As long as the links are semantically distinct, every user gets choice. Many browsers I've used don't offer a "personal style sheet," but every one I've used offers an "underline links?" toggle.

  38. As a student, I am really appreciating everything that I learn from this site. It is great that we can provide so many accessibility options for people who would otherwise not be able to use the Internet.

  41. Actually, no, the RNIB does not “recommend the use of clear print *instead of* large print.” The document (a PDF) says: “the RNIB advocate[s] clear print as an alternative to large print…. For many partially-sighted people, well-designed print information at 12 or 14 point is satisfactory.” Nobody’s replacing anything here.

    They then go on to queer the deal by essentially recommending you use New Century Schoolbook bold (or, I suppose, “Universe” bold, whatever that is). If that isn’t horrific enough for you, you can always follow their recommendation to use Arial bold without italics. By the way, what *are* “ornate” typefaces? I have a vague idea, but the last time I saw one of those was a tattoo on a guy’s back in blackletter.

    We are, in any event, discussing *Web sites* and not print.

    I would be rather surprised if the RNIB, known for its truculence and touchiness about Web accessibility (and for resolutely questionable advice for same), actually has verifiable research to back up the eyebrow-raising claims in this document.

  42. Tea Bore: > Two buttons, ‘change colors’ and ‘change layout’ in the top left corner might be a good solution.

    These functions should provide browser or OS on any page. Why implement “low-vision support” to every website? The only way is to improve browser and OS. Some applications do that even today (Opera, IE with Web Accessibility Toolbar etc.) so, why not the others?

  44. I’ve skimmmed through the comments quickly, but I didn’t see anything about my query. If we have a single column but fixed width layout, like many of the ‘current’ designs, to what extent do we need ‘zoom’ layouts?
    If someone has poor vision, I’m guessing they’d use a lower resolution to make everything bigger? In that instance the single column would be nearly full width, and the only thing in danger would be a horizontal navigation bar…
    Or have I missed something somewhere?

  45. If a user has standard assistive technologies installed, the feature in this article results in a “double zoom”. A violation of s508 since it constitutes interfering with an existing assistive technology.

  46. I’m glad to see discussion seems to be expanding to address the vast majority of people with visual impairments (VI). Most people with VI have some vision. In fact, only about 10% of the blind/VI population in the U.S. are totally blind. And yet most of the talk about acessibility seems to assume that users have no vision.

    I wonder how many web designers have really spent time watching how someone with a visual impairment, or any disability, works at a computer. My guess, not so many. A field trip to an agenty in your community that work with people with blindness and VI’s might be worth doing. Go see how someone really uses the computer, and what kind of technology is really being used.

    It’s great to read about studies and best practices, but nothing replaces experience. And just like any usability study, people don’t always do what you might expect, they do what is effective for them.

    By the way, I once did some training, in another field, using some devices that simulated some of the more typical types of VI. It was pretty revealing. If you are really intereted in this, mobility trainers (professionals who teach people with vision loss how to move about in the world) have these devices, and you can simulate this yoruself.

    Jeff

  47. For me, I love CSS and XHTML layouts – but I don’t really see what the point of creating an inverted CSS style, as most users that I know who are visually impaired will either have this turned on my default on their PC or Mac, or they’ll hate it!!

    And using an inverted stylesheet in this mode means they have to turn off their own settings!!

  48. Paul Ely, someone using a screen magnifier would have to *opt into* a zoom layout, just as someone not using a screen magnifier would. And it is not at all clear that a zoom layout that never exceeded the sides of the screen would be harmful to a user of assistive technology. So the zoom layout makes everything 15% bigger and the device makes it a further 50% bigger. I mean, you can’t just dial back your device to a lower magnification?

    So no, in fact, using a zoom layout causes no affront whatsoever to 508.

  49. This article recommends doing nothing to images in this zoom process.

    I am currently struggling with a way to make images of maps as clear as I can for anyone with less than excellent vision. Maps are very detailed, and while I _am_ providing text information alongside the map, many individuals are very visual learners, and a blurry map with a text description isn’t going to do them a whole lot of good. Why _not_ provide an option to a larger and clear image?

    Dagmar

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

I am a creative.

by
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career