Do It Myself Blog – Glenda Watson Hyatt

Motivational Speaker

WordPress vs Live Writer: The Image Smackdown

Filed under: Blog Accessibility, Blogging — by Glenda at 12:32 am on Thursday, March 12, 2009

WordPress versus Windows Live Writer In my blogging, I use both the blogging platform WordPress 2.7 and the offline editor Windows Live Writer 2009 for writing the posts. I have been amazed by how differently the two applications handle images. In fact, I have often wondered, usually late at night, which one is most accessible in terms of the images.

Today is the day to put the two applications in a byte-to-byte, no holds barred smackdown!

Round #1: Inserting an Image

The first step in inserting an image into a post is to identify the image.

In the Live Writer corner: the keyboard shortcut Ctrl + L opens the “Insert Picture” dialog box to choose the image from either my computer or from the web.

The Insert picture dialog box in Live Writer

In the WordPress corner: after some poking around, I found the keyboard shortcut Alt + Shift + M for inserting an image. This option is for an image that is already online.

The Insert/edit image dialog box in WordPress

If, however, the image needs to be uploaded, I must use the “Add an Image” button on the Upload/Insert toolbar:

WordPress Upload/Insert Media toolbar - First button is "Add an Image"

After some more poking around and reading Using Images in Posts, I could not find a way to activate the “Add an Image” button using the keyboard. Even by tabbing, I couldn’t reach the button.

According to the Authoring Tool Accessibility Guidelines (ATAG) 2.0 – Working Draft, which applies to both WordPress and Live Writer, “Authors with a wide range of abilities must be able to operate the functions and components of the authoring tool user interface.” Unless I missed finding a way to access the “Add an Image” button using the keyboard, this function is not available to bloggers relying solely on the keyboard.

Round #2: Using the Interface

The next step in inserting images into a post is to set the positioning or alignment, and to enter the alternative text (alt) to benefit individuals using screen readers and to make it searchable by search engines.

Picture panel - advanced tab in Live write Writer In the Live Writer corner: a straightforward interface in a sidebar for manipulating images. After poking around for at least half an hour, I could not find a way to get from the main Writer window to Picture side panel using the keyboard. That doesn’t mean a way doesn’t exist; I simply didn’t find it. Once in the side panel, the settings are operable via the keyboard. However, switching between the three tabs – Picture, Advanced, and Effects – using the keyboard also remains a mystery.

Under the Advanced tab, the alt text can be entered. Advanced? Alternative text is crucial to accessibility. One penalty point!

In the WordPress corner: the dialog box is not straightforward:

Add an image dialog box in WordPress 2.7

I am presented with four text boxes (or fields) without a clear understanding of what they are for. The Title box is marked with a red asterisk, likely indicating a required field; yet a note under the Caption box says “Also used as alternate text for the image. The Title is required, but the Caption is the alt? One penalty!

William Lawrence kindly explained the four fields in a comment on WordPress 2.7: A Brief Accessibility Review:

When inserting an image with WordPress all that is required is the Title which then gets used for the title and alt attribute of the image element. This is kind of good, because it kind of meets ATAG requirements, however because the content in the title and alt attributes are duplicated, this is inappropriate as it duplicates the context of the content. In addition, if one does not change the title of the image from an improper file name, the meaning is lost.

When one adds caption text, this additional text is placed next to the image and alt attribute of the image, while the title attribute of the image remains the title, or filename, of the image. This is kind of okay because now the image element no longer has duplicate content for these attribute, however the alternative text for the image now repeats what duplicated in the content of the article: inappropriate and repetitive.

Meanwhile, the description text is used as content for Attachment post page if one chooses to publish each image as a separate attachment post. More information can be found on their Codex for Using Image and File Attachments.

I need a flow chart to follow that! Another penalty.

Tip for bloggers: Because these two applications and many others do use the filename for the default alt text, make the filename more descriptive (and use a hyphen or underscore between words) when originally saving the image on your computer. This may not be the ideal alt, but it might prompt you to then revise the text when inserting the image.

Round #3: Validating the Code

Besides being accessible to me – the blogger, the application must also output content that is accessible to the blog readers. One way of measuring the content’s accessibility is to see whether the published code validates using a tool such as the W3C Markup Validation Service

In the Live Writer corner: the published code -

<img title="Glenda’s avatar" style="border-right: 0px; border-top: 0px; display: inline; margin-left: 0px; border-left: 0px; margin-right: 0px; border-bottom: 0px" height="178" alt="Glenda’s avatar" src="http://www.doitmyselfblog.com/wp-content/uploads/2009/02/glendabooksbyglendacom_ 102c1971.jpg" width="178"  align="left" border="0" />

- validates with no errors!

In the WordPress corner: the published code -

<div id="attachment_559" class="wp-caption alignleft" style="width: 188px"><img class="size-full wp-image-559" title="Glenda’s avatar" src="http://www.doitmyselfblog.com/wp-content/uploads/2009/02/glendabooksbyglendacom_ 102c1971.jpg" alt="Cute chick!" width="178" height="178" /><p class="wp-caption-text">Cute chick!</p></div>

- validates with no errors!

Frankly, I am surprised by this round’s results. This round was the one that had me wondering late at night. I thought the deprecated elements (code no longer used) and the repetitiveness of the title (in Live Writer) and the Caption (in WordPress) would have been marked as errors.

Bonus Round: Additional features

Although not directly related to accessibility, having extras for manipulating images are quite handy. It saves having yet another application open and switching between the two. Glenda's avatar with the added features of photopaper and slightly tilted

In the Live Writer corner: a variety of borders and actions (i.e. rotate, crop and watermark) that can be applied to images to add interest.

In the WordPress corner: zilch! WordPress is down. Its a knockout!

In terms of the accessibility of using images in posts, the winner is…Windows Live Writer!

If you enjoyed this post, consider buying me a chai tea latte. Thanks kindly.

Random Posts

Are Negative CAPTCHAs Any More Accessible?

Filed under: Blog Accessibility — by Glenda at 7:30 pm on Thursday, March 5, 2009

An example of a difficult to read CAPTCHA This morning I sat down to finish writing the “Do CAPTCHAs prevent your readers from commenting?” section for my upcoming ebook Web Accessibility for Bloggers. CAPTCHAs (short for Completely Automated Public Turing test to tell Computers and Humans Apart) pose many accessibility issues.

I recalled that, in a previous post about web accessibility, a reader offered negative CAPTCHAs – whereby spambots must prove they are bots rather than requiring humans prove they are indeed human when leaving blog comments – are accessible alternative. I googled negative CAPTCHAs to learned more about this alternative and started with Damien Katz’s Negative CAPTCHA.

Reading through the comments, which can be more informative and insightful, the following points were mentioned:

  • “a legitimate user on a browser which either doesn’t support or doesn’t have CSS enabled could fall for it”;
  • some browsers auto fill form fields and, thus, could conceivably fill in the hidden field;
  • a smart programmer could program bots to look for the hidden CSS tags and discard those field responses;
  • screen readers (software used by individuals with sight impairments) vary widely in how they react to hidden or invisible information as demonstrated by  Bob Easton’s research results (note: you would want a n/n for this instance);
  • “if you’re hiding a form field called "e-mail" from stupid bots, why not also include some explanatory text like "if you’re a human, don’t type anything in here–its just a trick to weed out spambots." sighted users will see nothing ’cause you’ve used js/css to hide the whole thing but the blind or people using lynx will read/hear an explanation.”

The discussion continued, but by then my eyes were spinning in their sockets and I was desperately craving chocolate! All I wanted to know was whether negative CAPTCHAs are accessible. Once again i was reminded that accessibility isn’t always a clear cut yes or no, but rather a continuum, which my clients always hate hearing.

So, I am taking the question to my brilliant and insightful people: Are negative CAPTCHAs any more accessible? Are they an appropriate alternative to the distorted characters in images used for blocking spam? If a blogger is using a good spam engine, such as Askimet, and requiring that the first comment of new readers be moderated (with an accompanying “Your comment is awaiting moderation” message – coming soon to this blog), is there even a need for CAPTCHAs to keep spam off blogs?

What are your thoughts on this topic?


A captcha with an audio feature Putting the ebook aside for the day, I next checked my email. In there was Viddler’s monthly newsletter announcing the release of its newest version, including “Captcha on forums” – like that is a good thing?! <insert sound of web accessibility consultant banging her head against the wall>

If you enjoyed this post, consider buying me a chai tea latte. Thanks kindly.

Random Posts

Can Your Blog Readers Find Your Hyperlinks?

Filed under: Blog Accessibility — by Glenda at 12:05 am on Wednesday, February 25, 2009

In the last web accessibility post, three tips were offered for making the content of hypertext links more usable. Today, consider the appearance of these links.  Can your blog readers easily spot your hyperlinks?

Which example below closest resembles your blog’s links?

Example #1: Links are indicated by colour only

Poorly indicated hyperlinks

In this screen shot, the link is indicated by a change in font colour. What if your readers have colour-blindness or low vision?

Colour should not be the only visual means of conveying information.

Example #2: Links are faintly underlined

Examples of faintly underlined hyperlinks

Can you spot the hyperlinks? Look closely. There are three of them, faintly underlined.

Example #3: Links are camouflaged by other coloured and underlined text

Example of poorly indicated hyperlink

In this screen shot, is the hyperlink the dark blue text, the red text with underline, or the black text with underline? Unless they hover their mouse over the different bits of text, how do your readers know where to click?

Example #4: Links are standard website blue

Hypertext links are blue with blue underline

In this screen shot, the hypertext links are standard website blue with blue underlining. Visited links become black text with black underlining – a nice feature so readers know which links they already followed.

Take a look at the hyperlinks in your blog posts. Are they easy to find? Or, do your readers need to hunt for them?

Additional resources:

If you enjoyed this post, consider buying me a chai tea latte. Thanks kindly.

Random Posts

3 Tips for Making Your Hyperlinks More Usable

Filed under: Accessibility 100, Blog Accessibility — by Glenda at 5:11 pm on Wednesday, February 11, 2009

How many times do you skim an online article or blog post, looking for interesting or relevant links? Individuals with sight impairments using screen readers (software that reads aloud text on the computer monitor) can have the software scan for hypertext links. However, oftentimes, the purpose of the hyperlink is difficult to determine. Similarly, individuals with other types of disabilities may face other obstacles while trying to use hyperlinks.

Web designers and bloggers can easily improve hyperlink usability by implementing the following three tips:

Tip #1: Make hypertext links informative when read out of context.

Imagine what individuals using screen readers would hear in the following example:

Examples of poorly written hypertext links, including "Click here"

In this example, the links “Christa Couture” and “Click here” are meaningless when read out of context. These individuals do not have any clue where the links will take them. The links should be rewritten to read “British Columbia singer/songwriter Christa Couture” and “View event details”.

Tip #2: Make hypertext links succinct.

Imagine how time consuming the next link would be to listen to, if you are scanning for only links:

Another poor hypertext link: an entire sentence is linked  

Making an entire sentence a link is unnecessary and is sloppy.

Tip #3: Separate adjacent links with non-linked, printable characters.

Imagine how confusing these two adjacent links would be if you had double vision or how difficult selecting the small links would be if you had a shaky hand:

An example of a poor hypertext link: two adjacent links with no separating character

In this example, rewrite:

“…running two Group Research projects…” (where each hyperlinked word points to a separate link)

to read

“…running the Internet Marketing Group Research Project and the Community Building Group Research Project…” (where the project names are hyperlinked and separated by the non-linked word “and”).

Other printable characters that can be used for separating adjacent links include punctuation, pipe bar |, brackets [ ], parenthesis ( ), and slash /.

Additional resources on hypertext links

(Re-examine the first two examples for a clue to next Wednesday’s web accessibility tip…)

If you enjoyed this post, consider buying me a chai tea latte. Thanks kindly.

Random Posts

Web Accessibility Not Only for People with Disabilities

Filed under: Blog Accessibility — by Glenda at 1:59 pm on Wednesday, January 21, 2009

While ringing in the New Year, I had for the first-time ever a clear vision and direction for the year: to share what I do know about web accessibility with fellow bloggers to build an accessible and inclusive blogosphere. But, what is web accessibility?

For the most part, people understand the need for ramps, elevators, high contrast signage, flashing fire alarms and the such to make the physical world accessible to people with all types of disabilities. But accessible websites? Isn’t surfing the web simply “point and click”? For some individuals, no, using the web is not quite that simple.

Like how people may enter your store using a wheelchair, walker, crutches or a guide dog, readers may visit your blog using assistive technologies (specialized hardware and software), mobile devices (i.e. iPhones and Blackberries) or even a dial-up connection.

Web accessibility enables all individuals to utilize websites and blogs, regardless of their personal capabilities or the technology they use.

Physical accessibility also benefits people without disabilities; for example, how many delivery guys hit the automatic door opener rather than trying to hold the door open while wheeling the cart through? Or, how many parents pushing baby strollers welcome curbcuts when crossing the street? Similarly, web accessibility also benefits people without disabilities.

Last month social media strategist Chris Brogan, who lives and breathes the web, sent the following sarcastic tweet when the Flash version of his bank’s website would not load for some unknown reason:

Message from Chris Brogan: My bank's stupid flash website isn't rendering, so I can't find info. Useful. Flash is so useful as the "meat and potatoes."

Because his bank also had a HTML-only version, an accessibility must for these types of situations, I found him the link and Chris was able to access the information he needed. (Note: perhaps the link to the HTML version needs to be in a more prominent location!)

Web accessibility benefits nearly everyone without most people realizing it until they cannot do something they want to.

If you enjoyed this post, consider buying me a chai tea latte. Thanks kindly.

Random Posts

« Previous PageNext Page »