Why Blog Accessibility?

Why have a blog dedicated to blog accessibility? Isn’t blog accessibility simply web accessibility guidelines applied to blogs?

Yes, blog accessibility is the same as web accessibility, but it is also different.

Let me explain:

When a “traditional” website is created, a team (sometimes a team of one) works together on the project. Granted, one or more pieces may be outsourced or someone with a specific expertise may be brought in. But everyone involved is working towards the end goal. And, if the team is any good, they will consider accessibility principles right from the beginning.

Contrast that approach with blogs, which are typically started by one individual with a burning passion or a keen interest needing to be shared with the world. Chances are this individual has little, if any, web design knowledge. Hence, the beauty of blogs: no technological knowledge (besides basic computer skills now mastered by kindergarteners) is necessary to begin sharing one’s thoughts with anyone who will read them.

Typically the blogger alone mashes together the blogging platform, theme, plug-ins and widgets to create the blog. Each one of these pieces impacts a blog’s accessibility (or inaccessibility), oftentimes without even realizing it:

  1. Blogging platforms – such as WordPress, TypePad and LiveJournal – have a double duty in terms of accessibility. First, the code produced by the platform, which is actually a content management system, should meet the Web Content Accessibility Guidelines 2.0 (or other appropriate guidelines). Accessible code benefits the blog’s readers. Second, the blogging platform interface – the part bloggers use when writing posts and such – should meet the Authoring Tool Accessibility Guidelines 2.0 (Working Draft). Accessible blogging platforms benefits bloggers with various disabilities.
  2. Theme designers control the blog’s layout, colour scheme, font sizing and such, which greatly impacts accessibility. If designers do not consider accessibility, many readers will be excluded from the blog’s community.
  3. Plug-in and widget developers create functionality and “shiny objects”, enhancing blogs’ interaction and interest for readers. However, once again, if accessibility is not considered when developing these plug-ins, many readers are limited or restricted from benefiting from them.
  4. Bloggers begin blogging largely to share a expertise or a experiences or to create a voice for themselves. Bloggers blog to create content and to build a community. Unlike website designers, many bloggers do not have training in HTML (HyperText Markup Language) or CSS (cascading style sheets). Further, some blogging platforms restrict bloggers’ access to their themes. These two factors limit bloggers’ impact on the accessibility of their own blogging community.

Let me demonstrate with an example encountered while setting up this blog:

Social Widget in WordPress

With the blog theme I am using, I am presented with the nifty Social Widget…type in the URLs of my various social media and networks – like Twitter, Facebook, YouTube and such – and the widget creates the links and inserts the graphics in the right sidebar. Quick, simple, easy.

However, clicking on each of the social media graphics opens a new browser tab or window, creating an accessibility issue.

When clicking on a link causes a new window to open, individuals using screen readers, individuals with cognitive impairments and those new to the Internet may not know a new window has opened. This can be confusing and disorienting. (I have seen an Internet newbie with 25 Internet Explorer windows open. When he clicked the link and the page did not change, he tried again and again until, in frustration, he declared the link broken and gave up.)

The solution is to announce, within the text link, that it opens in a new window; for example, the text link might read “Follow me on Twitter (opens in a new window)” where the entire text between the quotation marks is the clickable link. The other option is to not use the code target="_blank", which causes the new window to open and allow the user to decide whether a new window should be opened or not.

With the Social Widget, the graphic is the link. Announcing the link opens in a new window is not possible. After attempting to remedy the issue in other ways, I ended up using good ol’ HTML in a Text Widget, which defeats the purpose of having easy-to-use widgets.

This example raises several questions:

  • How are you, the blogger, supposed to know links opening in new windows is an accessibility issue? And, more importantly, what can you do to remedy the issue?
  • What makes a plug-in or widget accessible? What criteria can you use to determine whether a plug-in is accessible? Where are the charts comparing various groups of plug-ins, say social sharing and bookmarking plug-ins, to help you decide which plug-in to use based on accessibility?
  • What makes a blog theme accessible? What criteria should be considered when searching for accessible blog themes? Which specific themes are accessible?
  • What can you do to make your blog and your posts more accessible?
  • And, perhaps most importantly, why is all of this blog accessibility even necessary? How do people with disabilities use computers anyway? What barriers do they face while online? Does making a blog (and all websites) accessible really make a difference?

These questions and many more I intend to explore and answer on this blog. Several answers do not yet exist, at least in nice, neat packages. Dialoguing, discussing and even some (respectful) debating may be needed to deliver information and resources in a way bloggers can understand and implement.  You’re invited to join me for this journey and to contribute your experience, perspective and questions along the way. Are you with me?

3 Responses to Why Blog Accessibility?
  1. [...] is annoying and frustrating (to say the least), and highlights the point I made previously that a blog’s accessibility is impacted by four contributors: the blogging platform, blog theme, widgets and plug-ins, and the [...]

  2. [...] struck me in that moment that workflow is another way blog accessibility differs from web accessibility. Any worthy web developer or designer implements accessibility from the beginning of the project [...]

  3. [...] Great question! All of these accessibility requirements can be overwhelming. And, blog accessibility can be more cumbersome than web accessibility because of the four parties involved in each blog. [...]

Leave a Reply to Blog Accessibility: A Live Case Study | Blog Accessibility

Wanting to leave an <em>phasis on your comment?

Trackback URL http://blogaccessibility.com/why-blog-accessibility/trackback/