Blogging for Accessibility

In the time it takes to read this sentence a half dozen weblogs were created. In the last five months, the number of blogs worldwide doubled to 14.2 billion. It’s a blistering pace where a weblog is being created every second.

Weblogs, or “blogs” as they are affectionately called, provide a very powerful means for individuals and groups to quickly create websites and share with the world stories, news and opinions. Some blogging software is so simple to use that a person with no web design experience can create a site in minutes. As a result, blogs are impacting every inch of the Internet and real-world venues such as politics. Blogging can also be a very accessible way for people with disabilities to have their say as well. However, it does take a conscious effort to make blogging software and the resulting blogs accessible.

In this paper I will introduce this web phenomena and examine how it impacts people with disabilities, specifically sight-impairments. I will also review how the current and future web standards apply to blogging and provide tips and tool for making blogs more accessible.

Blogs and blogging

“I want a website!” A friend of ours came in to my wife’s pottery mad as a hornet. “The governor’s educational policies are awful.” Forget letters to the editor— she wanted a website.

I pulled up Blogger.com on my laptop and within minutes, she had created a website and posted two rants on the governor’s policies. She didn’t touch a web development program and she didn’t write a single tag of HTML. Yet, she is now a published writer with her own website. This is the power of blogs.

The biggest difference between blogs and “normal” websites is you no longer need to call the webmaster every single time you want to add content to the site. With a blog you simply pull up the new entry form, enter a title and some content, click the “publish” button and seconds later the information is posted to the site. Behind the scenes, this entry is being entered into a database which in turn displays the information on the web page based on templates written or selected by the writer. Once posted, the readers of the blog often take over leaving comments on what was just written, which can result in online conversations.

This whole process is called “blogging” and because so many people can now create blogs there is a democratization occurring on the web that is nothing short of revolutionary.

Blogs are often used as journals to track a person or group’s thoughts on their life or on a topic such as politics, technology or even pens. Most blogs are written by individual authors, such as my personal blog. Others are created by collaboratively by a community of writers such as LISNews.com which tracks library and information science topics.

Because new content is so easy to add, blogs are now being used to track breaking news events. During the recent London bombings, many people turned to bloggers for first-hand information about what happened. Blogs have also provided gavel-to-gavel coverage of conferences from the Computers in Libraries conference to the 2004 political conventions.

Businesses, political candidates and libraries are all starting to take advantage of these tools as well. From a practical standpoint, it allows anyone in an organization to contribute because no special coding or design talents are necessary. Similarly, it gives the organization a conversational voice to interact with their customers or members.

Libraries are using blogs to share news with their patrons, publicize events and publish lists of new materials. More creative uses include online book clubs where the patrons and librarians write reviews and share comments about books.

But is blogging accessible?

Blogging is only as accessible as the software you are using. For the most part, if the developers code to accessibility standards, both their software and the resulting website will also be accessible. However, inaccessible registration procedures, poorly written templates or not paying attention to details can still ruin an otherwise accessible program or blog.

Sometimes the problem is the software developer. In the early days of blogging the aim was simply to get the software to work. Accessibility was not a consideration. Unfortunately, some of this software is still in use today. A good example is Slash, which powers the super-popular geek blog Slashdot (sloganed “news for nerds, stuff that matters”). Administering Slash code is difficult at best, but it is still popular because it is highly customizable and can handle a large number of contributors.

One person who knows a lot about Slash is Blake Carver, host and creator of LISNews which also operates using Slash code. He had also just edited an issue of Reference Librarian about blogging so I emailed him about blogging and accessibility.

“You could certainly use LISNews as a bad example!” he wrote back. “I would love to make LISNews all CSS and XHTML, but (Slash’s administrative) back end stuff is a bear to work with, so it’s a pain to change anything. Many pages are hard to use, and it’s not at all intuitive. Slash powers LISNews and it’s written by good programmers that don’t care much about UI (user interface) and accessibility.”

Indeed, Slashdot is awash in code that can drive a person using a screen reader crazy— from the lack of headers to nonsensical links and nested tables. I will touch on all of these, but Blake Carver is correct, the answer is indeed XHTML and CSS and today’s best blogging software uses these two coding languages.

Extensible Hypertext Markup Language is the stricter successor to HTML that provides structure to the content of the website— much like an outline provides structure to a thesis. Through a series of “tags,” the code tells the reader which lines of the text are headlines, which are links and when we leave one section of content and start another. Cascading Style Sheets, on the other hand, take care of the presentation of the website — colors, fonts, column widths and much more.

Because you can easily swap out style sheets on the fly, you can then easily create a large-print or high-contrast versions for people with sight impairments. Some sites also use style-switchers for fun— it’s not unlike putting on a new set of clothes. To get an idea how separate the content and presentation can be, I highly recommend going to the CSS Zen Garden. The site demonstrates how the exact same WCAG/Section 508 accessible content can appear hundreds of ways, sometimes arrestingly so, using CSS.

The standards to follow

In the late 1990s, it was evident that the web was leaving large numbers of people with disabilities behind. As a result, standards were formed. The two most observed are the voluntary Web Content Accessibility Guidelines from the World Wide Web Consortium’s Web Accessibility Initiative (WAI) and Section 508 guidelines mandated by the federal government for all federal agencies and federally-funded projects.

The Section 508 guidelines that would apply to blogs would be part 1194.22 for web-based intranet and internet information and applications. In a nutshell, here are the recommendations:

• There must be a text equivalent for every non-text element and alternatives for multimedia presentations are to be synchronized with the presentation.
• The content should be readable without the associated style sheets. For example, any information or function conveyed with color and form should also be available without either.
• Image maps, where specific parts of a single image are associated with web links, should have redundant text links.
• All frames should have titles for identification and navigation. Similarly, all the column and row headers should be identified in data tables.
• When content or interface elements are made available through scripting languages, functional text alternatives must be provided.
• If a browser plug-in or outside application is required to view content, a link to tools that comply with the 508 standards must be provided.
• Forms need to be properly labeled to function with assistive technology including all field elements, submission buttons and other filing cues.
• Other requirements include avoiding design that flickers or flashes, providing means to skip repetitive elements such as navigation links and when timed responses are required, the user shall be alerted and given sufficient time to request more time.
• Finally, if compliance can’t be accomplished, a text-only page with equivalent information and functionality must be provided and kept current.

However, since these guidelines were approved in 1998, web technologies have changed dramatically. The emergence of Cascading Style Sheets alone has been a watershed in web development replacing many of the specific design techniques mentioned Section 508 such as frames, tables and scripted navigation. Thus, the WAI has been reviewing the new technologies and on 2 August 2005 closed the commenting period for the latest working draft of the web content accessibility guidelines to be known as WCAG 2.0.

This latest working draft covers only XHTML and CSS technologies which are those mostly related to blogs. Future drafts to be opened for comment will review other technologies such as scale-vector graphics and recent audio-visual content formats.

The WCAG 2.0 takes a different approach to creating accessibility. While Section 508, and the similar WCAG 1.0, used checklists of recommendations tied to specific technologies and design techniques, version 2.0 presents a more general series of principals, guidelines and success criteria that are independent of specific technologies.

The three guiding accessibility principals are straight-forward: Content must be perceivable, interface elements must be operable and content and controls must be understandable. Here are how these principals break down to guidelines and how they impact the design of blogs.

Principle 1: Content must be perceivable.

When you turn off the images and media on your website, are you missing any of the content? That is the question that the first principal aims to answer. In one’s blog, all non-text content, such as photos, graphs or multimedia, would have to have text alternatives that fully explaining the content. Dealing with multimedia is trickier. If the content is a live audio or video feed, text should be provided that explains the purpose of the unseen or unheard content. If the multimedia is prerecorded, the success criteria states it should come with captions and audio descriptions.

The guidelines in this principal also state that the blog’s information, function and structure should be separated from the presentation. Just as you should be able to determine content without graphics, you should be able to follow the site without having visual cues such as color and font size. The outline of the site should be evident by the content. For blogs today this means using XHTML and CSS. Yet, this is written generically to account for future technologies which I believe will lend staying power to WCAG 2.0 guidelines.

Principle 2: Interface elements in the content must be operable.

This is a catch-all principal that states all elements of the interface, such as menu bars, are accessible to all users. It also states that the website design should do no harm to the user either.

For example, the guidelines state that all functions of the website should be accessible through the keyboard and that the site should not force a users to complete a task within certain time period. These guidelines would be especially good for web surfers who face physically disabilities. Another example is to avoid flashing elements on the website that could cause someone who is photosensitive to have seizures. If the flashing elements are necessary, there should be posted warning and means of bypassing the content.

Finally, this principal states that the designer should “provide mechanisms to help users find content, orient themselves within it and navigate through it. For example, if a person is faced with an article of several sequential pages, there should be a way of knowing where they are in the article and means of skipping through it or completely out of it.

Principle 3: Content and controls must be understandable.

If the content of a website was in English, but the controls were in Swahili would you understand it? Probably not, so it is recommended web designers stick with a consistent language on their sites. Similarly we should explain, or have tools available to explain, any unknown words, foreign phrases, abbreviations and acronyms. For example, blogs are famous for excerpting news articles and adding commentary. If the article you find happens to be in French, identify the language and include a link to Internet translation tools such as Babelfish or Google’s language tools.

Unlike other WCAG criteria, which I believe would be applicable to nearly every website, I think their final criteria should depend entirely on the site’s mission. It states that when the text requires a reading ability at or above the high school level that simpler forms of the material should be made available— be it graphical, audio or simplified text.

If the mission of the site is to provide medical information to the general public, for example, then yes, it must have understandable content. However, blogs are often written for specific audiences and are often used to communicate within a profession. A medical blog oriented toward health practitioners would not likely be understood by many outside the profession. I do not believe this specialization violates the intent of the principals— otherwise the New England Journal of Medicine would need a cheat sheet.

The pleasure and pain of Blogger

Created in 1999, Blogger was not the first blogging software, but it is definitely the technology’s “grandfather” by making blogs easily accessible to the public at-large. Now offered by the folks at Google, Blogger is still the best and most popular entry-level blogging software.

While you can get free hosting and a decent feature list, the biggest reason people cut their blogging eye-tooth on Blogger is that it is very easy to use. For people with vision impairments, Blogger offers a straight forward interface that passes both Section 508 and WAI verification checks. However, there are a couple possible deal breakers.

The set-up process is a good example as it appears to be a simple three-step process— create an account, name your blog and pick a template for how your blog will appear. That’s it and it actually is very easy— unless you use a screen reader because on the second step Blogger commits a cardinal sin of accessibility.

Blogger, and many other web service companies actually, fear that a person with a computer program will take advantage of them by automatically signing up for scores and scores of blogs. To prevent this, Blogger makes you jump through a hoop called a CAPTCHA— Completely Automated Public Turing Test to Tell Computers and Humans Apart.

This verification method asks you read a series of distorted letters from an illustration and type them into a box. Unfortunately, this task is impossible for someone using a screen reader. Some services, such as Microsoft’s Passport services, allow for alternative verification methods. However Blogger does not and that’s the cardinal sin.

Example of Blogger’s CAPTCHA “word verification” form: ? “Type the characters you see in the picture:”

Once you’re in, Blogger provides more than 30 good looking, Section 508 validated templates for a person to choose from. However, the minute you drop a photo into your blog, accessibility becomes harder because Blogger does not provide an easy method for describing your photos in “alt” tags.

You upload a photo to Blogger much the same way you would place a photo into a word processor. However, to create an “alt” tag you then need to click on the “edit HTML” tab, find the appropriate image tag and fill in the empty alt tag yourself.

A better way of doing this would be to have a field called “description” in the photo upload box. Then when the photo is placed, the description field information would be automatically used for the alt tag. This is how the blogging program WordPress handles this task.

While blogging software can certainly help the writer “do the right thing” by making the creation of “alt” tags easier, the bottom line is the blogger has to take responsibility for whether their blog is accessible. Even if a description box is provided, you still have to fill it out.

I think the choice of blogging software comes down to the computer skills of the user, whether the person has a sight disability or not. If a person has little to no knowledge of XHTML or CSS, then Blogger is still the best option. From my personal experience, I much prefer Textpattern and Movable Type. However, to install this software or change a site’s appearance, a person has to have at least a cursory knowledge of XHTML, CSS, FTP, mySQL databases and sometimes Perl or PHP. It should be noted that many web hosting companies will install blogging software for you— Movable Type, for example, offers its pay service TypePad so it’s ease of use approaches Blogger.

Designing for sight-impaired web users

Whether you are using Blogger, Textpattern, Movable Type or WordPress, here are 10 tips to make your blog as accessible as possible. Some of these tips are basic, others deal with the underpinning style sheets and templates. They are gleaned from several sources including a series of good videos produced by the University of Wisconsin Division of Information Technology and a cheat sheet on making blogs accessible from the American Foundation for the Blind.

Tip One: Make your fonts relatively sized.

The fact most blogs use XHTML and CSS puts a good foot forward. However, there are multiple ways for any given feature to be coded. Font size is a good example as you can set the size relatively or absolutely. If you express font size in percentages or “ems,” then a person with low sight can easily enlarge the type proportionally with a key-stroke in the browser. If you use absolute specifications such as points or pixels, this may not work.

Tip Two: Describe your images

As noted above, describing your images is mandatory for an accessible website. Provide alt tags and descriptive text for every images you post, including those that are part of your template. For example, the header of my blog has a photo of an Egyptian goose with the words “Life on the River’s Edge” overlaid transparently on the image. Its existence would go unknown to a person using a screen reader because, currently, there is no alternative description. This is how my image code reads:

Here is how the code should read:

The rule of thumb is to be brief, clear and informative with image descriptions. While you should avoid being overly poetic, it does not mean you have to eliminate style. Tags can be used to convey the overall feel of a website just as you would use graphics to convey an attitude.

If the graphic includes text, as my header does, you should also include the text in the alt tag as well. Place the words before the image description in the tag if that is the most important part of the image.

Tip Three: Make your links and entry titles descriptive.

Non-descriptive links and blog entry titles are two common mistakes in blogging. The first error is committed when you write about a great website then end the sentence saying “click here.” The latter is when you write a cryptic headline that only makes sense when the person reads the rest of the entry. Here is why you want to avoid both problems.

When a person who uses a screen reader visits a website, they will often skim through the site by listening only to the links and the headers. This gives the reader a sense of the navigational options as well as get a feel for the site’s content. This way, any explanation for the “click here” link or the cryptic headlines are entirely missed.

A similar problem arises when the homepage shows only an excerpt of a longer entry with a link that states “more…” If you see this link out of context it makes no sense. Excerpting lengthy posts is a good idea, but use a more descriptive link such as “continue reading [name of post]…”

There is a bonus for using descriptive links and blog post titles. When search engine “spiders” examine your website, they travel via the links as they harvest the text of your site. The search engine’s algorithms in turn give priority to the text found in links and headers. So when a person searches for a term that matches your entry titles or links, it will rank higher in the results.

Tip Four: Make sure your site outline flows.

The tags used in XHTML not only call on CSS definitions to give the website an appearance, but they also provides structure to the site and guidance to the user of a screen reader.

If the blog title is tagged as header one

, the title of an entry as

, content subheaders as

and blogroll headers as

, the person listening to the screen reader can then follow this logical outline of the site, knowing that header 2 is more important than header 3. If you skip around, this flow is lost.

Tip Five: Put your “blogroll” on the right-hand side

Blogs have several consistent features. One is a list of blog archives, be it by time period or topic. Another is a list of blogs and websites the writer frequents. This list of links, which can be very long, is known as the “blogroll.”

Stylistically, many people like to see this list on the left hand side of the page. However, because screen readers start at the top of the page and read left to right, going through this list with a screen reader is time consuming and annoying at best. Thus by placing the blogroll on the right-hand side, the screen reader user can go right to the new content. If you have to put the list on the left side, provide a link allowing screen reader users to skip from blogroll to the content.

Tip Six: Check labeling on comment forms

As noted, one of the important facets of blogs is the ability to respond to what the author writes. However, if your comment form is not properly labeled, a person using a screen reader would not know which entry field is for name or comments. According to the AFB brief, “the user moving through an incorrectly marked up form may hear no more than ‘Edit, edit, edit, radio button not checked, submit button.’”

Simply using the tag can fix this problem. Many blogging software programs will do this, but double check the HTML markup to be sure that every element in the form has its own label. For example, here is a text field that has been labeled correctly for email (note the label and id are the same):
E-mail:

Tip Seven: Watch your use of color.

As noted in the standards, color should never be the sole means of communicating information or function in a website. Even so, proper use of color can still be very helpful to people with sight impairments.

In one of the University of Wisconsin videos, graduate student John Klatt shared his experience using the ZoomText screen magnification program and demonstrated its use on UW’s homepage. Without the magnifier, he could not read the site. Indeed, he could only see large patches of color. Using ZoomText, however, he was able to find two sets of navigational links on top of the site. What he specifically liked was the designer used sharply contrasting colors to differentiate the two sets of links. Here, Klatt said the smart use of color helped him navigate the page and avoid errors.

Meanwhile, 1 in 12 people have problems perceiving color which is often known as color blindness. While some assistive software can filter in and filter out various colors, a blog designer should still watch how they use certain combinations, such as green and red, where the colors would disappear to someone with color blindness. A useful tool is the Color Scheme Generator, which not only helps a designer find pleasing color combinations, but also shows how those combinations would look to someone with the varying forms of color blindness.

It is also recommended to look at your website without color, either by changing your monitor to grayscale, by printing it out in black and white or looking at your site through a program that strips the color. This will help eliminate possible areas of color conflict.

Tip Eight: Don’t Force Links to Open in New Windows

The is an argument that says all outside links should be opened in new windows so the user will know they are going to an outside web source and so your site remains open to be seen again by the user.

However, this is extremely confusing to people who use screen readers for two reasons. First, only the most recent screen readers even tell the user a new window has popped open and second, they then cannot use the back button to go return to your website. Thus, avoid using the target-new or commands in your code.

Tip Nine: Use keyboard accessible links.

With XHTML, you can attach keyboard commands to website links and it’s easy to do using the accesskey tag. Home

Some designers underline the letter H in home to signify the access key. In this case, there is also a “title” tag that pops up a floating yellow box when you mouse over the link to signify the access key availability. On a PC, you would use the key combination alt-h to access the homepage here and on a Mac it would be control-h. This also assists people who have physical disabilities that hamper use of a mouse.

Final Tip: Don’t trust your web browser

In an ideal world, if we properly developed our sites using web standards, our websites should look exactly the same in every browser. Unfortunately, that’s not the case so it is highly recommended web developers take a look at how their pages looks on different browsers.

Unfortunately, the laggard in the crowd is the aging, but very popular Microsoft Internet Explorer. The worst offense is that IE slaughters the display of modern CSS. I have also seen websites with overlapping text in one browser that look fine in another.

The only way around this is to test your site using different browsers and tweak your code until you get it right. Often you either have to hack your code so it will look presentable in IE or stick with the standards and admit it will never look right in Internet Explorer.

One tool to help in this process is Browsershots.org, an open source project where people all over the world are willing to make screenshots of your website using different browsers.

Tools to make the process easier

There are numerous tools that can help a developer create accessible websites. Because blogs are often websites on the cheap, the availability of free tools is a blessing. In addition to those I have linked to in this paper, here are three more free tools I now find indispensable.

For me, the first step is getting a good, standards observant web browser. The best, in my mind, is the cross-platform Firefox browser from the Mozilla project. In addition to correctly displaying properly written code, there is a huge developer community which has created a slew of valuable “extensions” that broaden the functionality of the browser. Two specifically designed to help develop accessible websites are the Web Developer Toolbar and Fangs.

The Web Developer Toolbar, created by Chris Pederick, was developed to allow the designer to see beyond the face of the webpage. To insure the site is meaningful without images or color, simply disable them through the toolbar. Indeed, you can strip all style sheets from a site and examine them as well. It can find empty alt tags and show all the header and content tags in the text so the designer can see whether the text would flow in a screen reader. There are about 100 functions stuffed into this great program including instant links to a half-dozen verification services that will check whether your website is valid according to section 508 and WCAG recommendations.

Fangs is a Firefox extension created by Peter Krantz of Sweden that emulates how the JAWS screen reader will read your website. In a series of tabbed windows, it “writes” what the screen reader “reads.”

The first window writes out the copy as it would be read by the screen reader in general— announcing headers, links and tables as they are encountered. This readout is useful to insure the flow of information makes sense and helps you avoid problems such as nested tables which would be read by the program repeatedly as “Table with four columns and five rows. Table with two columns and four rows. Table with three columns and two rows…” In the program notes, Krantz writes that run on sentences and misspelled words also sound horrible on a screen reader.

The second and third windows list all the links and headers. If these lists make sense and tell the reader about the site and the content, you’re doing well. However, if the site doesn’t have a single header, or if the headers skip numbers the user will not be able to find what they are looking for. Similarly, this list of links can show you if you are committing the “read more” faux paux instead of descriptive links to extended entries.

Conclusion

One of the coolest things about having a blog is knowing someone out there is reading it. Many bloggers work to find ways of reaching larger and larger audiences. However, if the site is not accessible, you are only turning away possible readers. So from a practical standpoint, fulfilling accessibility standards make sense if you want the largest possible audience. If you are running a blog at a library, our mission of serving all patrons makes this effort doubly important.

However, even ignoring the possible readership gains, it’s still the right thing to do. Blogs are allowing nearly anyone to post their thoughts and experiences on the Internet. In turn we can all read about them. This is truly a small-d democratic notion. To close off a blog or the blogging software due to a lack of accessibility violates this core blogging concept.

Finally, it is at this point that I must acknowledge my own failures. I enjoy making websites, but I knew only a couple of these rules— basically I only knew to use CSS instead of tables for my presentation. So it was an ugly scene when I sent my own blog through the verification process— mainly I was hammered for a total lack of alt tags. Thus, I obviously have some work to do to correct these shortcomings once this class recesses.

References

Note: These are my information sources, programs and websites are linked throughout the document.

American Foundation for the Blind. 2005. “How to Make Your Blog Accessible to Blind Readers.” Available from: http://www.afb.org/Section.asp?SectionID=4&TopicID=167& DocumentID=2757. Accessed 29 July 2005.

American Foundation for the Blind. 2005. “Is Blogging Accessible to People with Vision Loss?” 2005. Available from: http://www.afb.org/Section.asp?SectionID=57 &DocumentID=2753. Accessed 28 July 2005.

Carver, Blake. 2005. “Comments on Accessibility of Lisnews.Com.” email with E.G. Yarnetsky, 17 July 2005.

Carver, Blake. 2003. “Is It Time to Get Blogging?” Library Journal 128 (Winter Net Connect): 30-32. Academic Search Elite.

Center for IT Accommodation. 2002. “Section 508 Standards, Technical Standards.” Available from: http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web. Accessed 6 July 2005.

Dance, Jennifer. “The Web Developer Extention for Mozilla-Based Browsers.” WebAIM: Web Accessibility in Mind, 2005. Available from: http://www.webaim.org/techniques/ evaluating/devtoolbar/devtool. Accessed 20 July 2005.

Lacey, Sarah. 2004. “For the Blind, a Welcoming Web.” Business Week Online, (27 October). Academic Search Elie.

Lescher, John. 2000. “Designing Web Sites for the Blind.” EContent 23, no. 1 (April/May): 14-21. Academic Search Elite.

Perrone, Jane. 2005. “Every Second a Blog – but Not for the Long Slog.” The Guardian, 3 August 2005. Available from: http://www.guardian.co.uk/uk_news/story/ 0,3604,1541357,00.html. Accessed 3 August. 2005.

Stone, Biz. 2004. Who Let the Blogs Out? A Hyperconnected Peek at the World of Weblogs. New York: St. Martin’s Griffin.

University of Wisconsin Division of Information Technology. 2004. “Screen magnification for the web.” Available from: http://www.doit.wisc.edu/accessibility/video/ screen_magnification.asp. Accessed: 7 July 2005.

Web Accessibility Initiative of the World Wide Web Consortium. 1999. “Web Content Accessibility Guidelines 1.0.” Available from: http://www.w3.org/TR/WCAG10/. Accessed 29 July 2005.

Web Accessibility Initiative of the World Wide Web Consortium. 1999. General Techniques for WCAG 2.0: Draft. Available from: http://www.w3.org/TR/WCAG20-GENERAL/ Accessed 8 July 2005.

Wikipedia. 2005. “Cascading Style Sheets.” Available from: http://en.wikipedia.org/wiki/ Cascading_Style_Sheets. Accessed 31 July 2005.

Wikipedia. 2005. “XHTML.” http://en.wikipedia.org/wiki/Xhtml. Accessed 31 July 2005.