Intro to Web Page Accessibility
Copyright © 2022 by Steve Litt
See the Troubleshooters.Com Bookstore.
Let's start with a little story...
My vision is correctable to between 20/30 and 20/40. No problem, I wear my glasses and set up all my applications for large fonts, black type on a white screen. No transparency. No subtle color contrasts.
A new Linux distribution (we'll call the distro "Tiny Font Linux" to protect the guilty) was formed around a novel and quite good idea for packaging. I was enthusiastic and told them so. I offered I offered to publicize their distro on Troubleshooters.Com. Given Troubleshooters.Com's credibility in the Linux world, this would have helped them gain users, testers and developers. I was very enthusiastic.
But their desktop featured between 7pt and 9pt print, dark purple on dark blue. I couldn't read it, which means I couldn't adjust the size or contrast, either with a tool or an editor. No problem, I'd just boot to command line and edit from there. Bzzzzt, wrong! They had configured their framebuffer for tiny fonts. When I blindly tried to start their packaged editor, nano (no Vim available without installing a package I couldn't see to install), nano had tiny fonts unreadable to me. It was a buried shovel: If I could have read it, I could have enlarged it, and if I could have enlarged it, I could have read it.
No problem, I wrote on their project mailing list that they needed to at the very least have an easily installable large-faced, higher contrast interface so someone with bad vision could configure fonts. They basically said they were too busy, and even went so far as to say it might be impossible. I guess every other distro must have some kind of magic, because few of them have this problem.
To make a long story short, they refused to fix it in a meaningful timeframe, they portrayed my continuous asking about this as "annoying people and alienating them from your cause". They told me to hit Ctrl++ as if their desktop environment was a browser. I did that, and of course it magnified nothing. Finally, they asked, and I quote, "Have you considered making the patches yourself, and sending it in?" Now how am I going to make patches on something I can't read and can't enlarge?
I gave up. The only publicity they got from me was when someone asked about Tiny Font Linux, I told them this story, and the people asking generally never did anything more with Tiny Font Linux.
Troubleshooters.Com has credibility in the Linux world. This isn't an idle boast. Ask around in the Devuan, Void Linux, LyX and Inkscape communities, and they'll confirm it. I could have helped Tiny Font Linux quite a bit, but they blew me off because it was too much trouble to make their distro accessible to a person with a very minor visual handicap.
Tiny Font Linux got a lot of mention back in 2017, but their project withered on the vine. There is no mention of them on DistroWatch today, and the last message on their mailing list is from late 2019. They failed.
Note:
When I use the word "you" in the next few paragraphs, I don't mean you, the individual now reading this material, I mean a generalized "you" that's short for "the person or organization who makes the web page."
The moral to this story is that, although it might seem a good idea to appeal to the majority and ignore the handicapped, it's a very bad idea, and not for moral, altruistic reasons, but for very personal and dollars and cents reasons. Ignoring the handicapped can hurt you in ways you know, and in ways you'll never know.
I'm not saying you should spend days, weeks and months making sure your site is accessible to every last person. You have budgets to keep and deadlines to make. The perfect is the enemy of the good. All I'm saying is do the easy stuff right now. How much effort does it take to put alt= on any img elements on all future construction? How much effort does it take to avoid the colors red and green from being meaningful on your web page. When somebody takes the time to email you with a suggestion how you can change the web page so they can work with it, if that suggestion isn't hugely difficult, why not do it? You never know when "that blind guy" is a CEO's son. Or a CEO.
The next section of this page describes some generalities about accessibility.
There's a reason this page is called Intro to Web Page Accessibility. This page just scratches the surface. Web accessibility is a huge subject. I'd imagine it would take two semesters of four-credit-hour college courses just to get into accessibility in a meaningful way. I can envision that a big company with a big budget might hire an accessibility expert to give guidelines at project start, and repair and evaluation at the end.
The average Troubleshooters.Com reader isn't a CEO. In fact, a lot of our readers are the sole maintenance of a website. So this document addresses some fundamental principles and low hanging fruit. Most advice in the following sections addresses visual handicaps, but there's some guidance for other types of handicaps too.
When we speak of accessibility for visual handicaps, let's start with the low hanging fruit: Things that are trivial to do on new construction, and pretty easy retrofits on existing pages...
It's pretty easy to accommodate people correctable to 20/40 or maybe even 20/60 or 20/80. It's just common sense.
I mentioned in the Introduction some geniuses putting dark purple text on dark blue background. I'm sure such color combinations win design awards from fashionistas, but using such a color combination is a huge "Forget You" (you know what I really mean) to the person correctable to 20/40 vision.
There's no better contrast than black on white or white on black, and if you use white on black you'd better have a heavy typeface. Now of course the fashionistas will scream bloody murder at such stark contrast, and various people will complain about black type on white background giving them headaches. I guess the headache crowd doesn't go on mostly black on white Facebook, or almost completely black on white eBay, or quite a bit black and white Amazon.
If you want to accommodate both the visually handicapped and the brightness-causes-headaches crowd, you could do the following:
This paragraph is in a white on dark green div. Use white on dark green. Dark green is very restful, yet in both color and intensity it contrasts incredibly with the white text, so most people can read it.
This paragraph is in a white on dark blue div. If you're not concerned with restful, but want contrast with a background color other than black, consider white on dark blue. Once again, contrasts excellently in both color and intensity.
This paragraph is in a light yellow on dark blue div. This has good intensity contrast, and outstanding color contrast. Also, it's well known that yellow and blue go well together.
Did you notice that in the preceding three paragraphs I announced the paragraph's color scheme. Why did put in that redundant information?
That information isn't redundant for those totally color blind (monochrome vision) and those who can't see at all. This is an example of keeping the visually disadvantaged in mind.
Everyone adjusts their browser's text size to suit their needs. The 20/10 guy uses 7 point so he can have a small browser window and have lots more windows on his screen. The 20/40 guy uses 20 point to read effectively with minimal eyestrain. It takes a special kind of conceit to override the visitor's font sizes. The web developer has no business overriding the visitor's needs.
I'm not saying the web developer should have all text the same size. Certainly headings are bigger than the standard text the user sets up, and the source code text might be a little smaller than standard. What I'm saying is that every size the developer declares should be based on the standard text size the user configured into his browser, and the size for the page's standard text should not diverge from the user setting. In other words, the following CSS is bad practice:
p{font-size:140%;}
I think the major reason for overriding the visitor's preferences is inferior HTML/CSS knowledge and ability. You know, these designs where all the text overwrites other text if the text size is cranked up to, let's say, 16 point. They're probably using tables for multiple columns. They've never heard of foldunder divs, foldunder flexes, or media queries, just to name a few ways to do columns right, without them overprinting each other.
Some web designers might be under the mistaken impression one page should contain a hundred links and twenty advertisements. Those same web designers usually have no structure organization, disenfranchising both the totally blind and those with ADD (Attention Deficit Disorder).
In printed books, they usually use Sans Serif headlines and serifed body text, and it looks great. In printed books. But on a screen, more and more web developers have switched to sans serif for everything or almost everything. This includes Amazon, Facebook, Youtube, Wikipedia, and most of Ebay. They're not using Sans Serif because it's the hip new thing, they're using it because it's more readable.
On most browsers, the default line and paragraph spacing is too small. Larger line spacing reduces fatigue by making the next line obvious when you shift your eyes from the right back to the left. The following is the main paragraph style for the Web Workmanship subsite:
p{ margin-bottom:2.2ex; line-height: 160%; }
The preceding CSS specification specifies a line height of 160% of normal, and a bottom margin of 2.2ex, which is visibly and obviously bigger than the 160% line spacing, so picking out paragraphs is trivial.
Note:
This document uses the phrase Visual Adaptive Technologies to refer to things like screen readers, HTML to speech, HTML to Braille, and other technologies helping the blind to read a web page. Visual Adaptive Technologies can also be abbreviated "VAT" within this document.
Here we're talking about corrected vision worse than 20/80, and also total blindness. In other words, people who need Visual Adaptive Technologies. The key distinction is this: The well sighted or even marginally sighted live in a 2 dimensional world on the web. They can scan through the entire screen to find what they want. Those using Visual Adaptive Technologies live in a one dimensional web world. They must read in DOM order. For those Visual Adaptive Technologies, there's no such thing as "glance".
On encountering a web page, the well sighted visitor glances all over the page, picking out navigation, links, images, and text, and then decides what to do. How different it is for the user of Visual Adaptive Technologies (VAT). With VAT, reading is started at the beginning and progresses linearly through the whole document. If you're well sighted, to understand what a hassle this is, compare your experience with a menu in a browser or computer program, compared to an audio menu in a phone answering system. If you're anything like me, as the choices drone on, you're thinking "Come on, get on with it." If you miss one choice you need to take extraordinary steps to re-hear the choice. There are usually five or six choices on a phone menu, so if you're anything like me, by choice 4 you've forgotten choices 1 and 2, so need to go back. Is it any wonder that people hate phone menu systems? Now imagine websites worked like this. Well, this is what blind people encounter every day. Bless them for their patience! There are things web developers can do to ease blind peoples' burdon...
Some things are, or should be, obvious:
Many Visual Adaptive Technologies are capable of telling the user (visitor) whether what they're reading is an h1, h2, h3, h4, h5, h6, ol, ul, or li. The blind person uses this information the same way the well-sighted use heading size, color, indentation and weight to deduce the structure of the document.
In addition, the HTML5 spec defines the header container element, which tells the blind visitor where the header material stops and the main material begins. HTML5 also bestows the footer container element to tell the blind person where the main material stops and the footer material begins. These can theoretically be used in lower level structures to separate header, main matter and footer for one or more lower level structures (h1 through h2). I've never before used header and footer, and am studying them in regards to best use. I have the feeling that, if used wrong, these will confuse the blind visitor more than help him, and they make your structure and DOM (Document Object Model) one level deeper, and thus more complex.
There's also an article container element to contain a section that's a cohesive article or reading piece. The article container element might be useful, on this page, for blind people. But again, it adds DOM depth and complexity, so I'll need to study it more.
Long story short, the more logically you structure your document, the more understandable it is to the Visual Adaptive Technology using web visitor.
As mentioned, the blind visitor must read the page linearly. He or she cannot "glance", so they can't easily skip every-page navigators or advertisements the way well-sighted people do.
In the case of advertisements, I think the ideal would be a simple media query that would render every ad as display: none if the web page is being read by a Visual Adaptive Technology, but my research tells me that for the latest media query spec, Level 4, @media speech has been deprecated, so apparently there's no way to distinguish a Visual Adaptive Technology from an ordinary browser. This is a travesty.
The next best thing is to offer a quick and sure way to skip over ads, presented before each ad. This won't lessen the exposure of well-sighted visitors to the ads, but it will hugely speed up Visual Adaptive Technology users, who are forced to traverse the page linearly.
I know very little about auditory handicaps, so I'll just state the obvious:
I know almost nothing about this, but I have one suggestion: Distance click points far from each other, and if possible make click points large, and make sure that a click anywhere in the click area actually triggers the action. The following is the right way to do it, using a yellow rectangle (div) as the click area. The yellow div contains a link whose main function is telling the purpose of the click:
In the preceding, note that no matter where you hover or click within the rectangle, your hover or click is recognized. Anyone with a reasonably steady hand can successfully operate the preceding. Note that in order for the mouse pointer to change to a finger or whatever indicates you're on something clickable, you need the following in the div's CSS.
cursor:pointer;
It seems like underlined links are out of fashion with the fashionistas, so you could remove the underline with the following CSS, assuming the div has class "goodclick2":
div.goodclick2>a{text-decoration: none;}
Before removing the underline, consider that underlining gives one more cue that the text is a link. The following is the right way except that the link's underline has been removed:
The following is a the wrong way to do the same thing, once again with a yellow rectangle:
In the preceding example, only the link itself is clickable. Not only is the preceding misleading, but a person with a slight tremor will have trouble with it, and it probably completely rules out someone with sever palsy or a serious stroke survivor.
Finally, let's look at a paragraph with links so close together that someone with no handicaps at all could easily fatfinger it:
Just click here no wait I mean click here or perhaps click here unless you really want to click here or perhaps click here.
The preceding was a paragraph with lots of links, a narrow width of 200px, and very tight line spacing, so that some of the links are directly above and almost touching others. Unfortunately, you see a lot of such tightly packed links on various websites. Links like these are a menace on a mouse-equipped browser, and an impossibility on a small device or in the hands of somebody whose hands shake even a little.
Finally, the following uses real button, so it accommodates folks with physical maladies, but also better accommodates those using Visual Adaptive Technology because it's a real button:
The preceding is big, easy to click, semantically portrayed to the blind user as a button which we all know is meant to be clicked. It's perfect, except for the artiste`s among us who simply can't abide with the gray color. No problem: The following is a colored version of the same button, with a bisque background color, orange hover color, and red click color:
You can see the CSS that colored this button in the source HTML of this page, so you can see how to apply absolutely any color you want.
Because the preceding two buttons are so huge, it stops looking three dimensional. You can bring back the three dimensional edges with the following CSS applied to the button:
border-width:4px;
Big click buttons made from real buttons are probably the most useful way to accommodate visitors with physical motor problems while also accommodating those with either poor visual acuity, no vision, or Attention Deficit Disorder (ADD).
For everyone with an IQ of 120, there's someone with an IQ of 80. That's just how bell curves work. People with IQs of 80 have money to spend, so don't blow them off. Rid your page of ambiguities. Prefer repeating the name of something to saying "it", especially when several things have been named in the preceding paragraphs. Find simple words to use. Augment your text with diagrams and plenty of examples, so people can deduce what you really mean. Unless the web page's sole purpose is vanity, there's nothing gained by confusing the visitor.
Now let's speak of visitors with Attention Deficit Disorder (ADD). A heck of a lot of the population has this trait, and many can't or won't take pills for it. Until the last thousand years or so, ADD was a survival trait: You kept scanning for the nearest predator or prey, ready to act in either case. Understanding a profound concept was of secondary priority when you needed to eat and avoid being eaten. If your web page is ADD-hostile, you'll lose a lot of important visitors, including some CEOs and CIOs.
Before discussing how to accommodate those with ADD, let's look at an ADD-hostile web page. Notice some of the deficiencies:
The preceding list pretty much spells out what you should do:
A final thought for the mental disabilities section: The reasons for the success of Troubleshooters.Com, my courses and courseware, and my books including the critically acclaimed Samba Unleashed include the following:
If you write the way I described in the preceding list, you'll accommodate most mental handicaps.
You're almost done with HTML and CSS. Your next step is to read HTML/CSS/JS Quickhacks, which at this point you'll probably find trivial to understand.
There's a reason this page is called Intro to Web Page Accessibility. There's always more to learn about this subject. Although no web page is totally accessible to all visitors, my hope is that after reading this page, you at least employ some of its suggestions on web pages you build in the future. And who knows, if your web pages are based on a separate CSS file of your own making, you might be able to retrofit already built pages just by changing that CSS file a little.