Accessibility Archive

Publishing for Access

Let’s face it, when you’re authoring stuff you want your thoughts to reach the broadest audience possible. You want to make sure that your ideas get to your audience just as you intended without missing any valuable content. In short, you want your content to be accessible. Despite a variety of tools and guidelines, there are still too many materials on the web that are inaccessible across the diverse products that people use to connect to the information that they need.

If we think a little bit about the people we are trying to reach, we quickly realize that they access the web using smartphones, tablets, slates, video game consoles, televisions, notebooks, screen readers, braille displays and even desktop computers. Some authors might simply shrug and note that if someone can’t see their blog post on a portable device that their readers will come back to visit on their desktop at a later time. I have to disagree that readers will come back and more importantly suggest that there are a number of people that rely on a single way to access the stuff that you post. I’ve heard first hand of the frustration experienced when information is not accessible by people who rely upon specialized tools to use their computers.

There are some very easy ways to prevent the frustration.

1. Think about the different ways people might get at your information – Awareness is often the first step to making information accessible. So consider the individual reading your materials on the small screen of a phone or having the information read aloud by a screen reader. If you haven’t experienced the ease of access tools (e.g. Narrator, Magnifier, High Contrast, etc.) give them a try (just press the Windows key and “u”)

2. Appreciate the details –There are a few things that authors should consider when creating content that can be consumed across a variety of devices. Considerations such as providing textual descriptions of the images or making sure presentations build and flow correctly. A common gotcha is saving a document as an image file thereby losing the ability to have it narrated by a screen reader.

3. Consider the tools at your disposal – As with many other communications technologies, there are a number of techniques available to help you reach the broadest audience possible. Some of these techniques vary with the role that you might have; be it a software developer, a web designer or content creator. A common pitfall is to look narrowly at one approach, say a web only model, and inadvertently restrict other useful techniques (for example, downloadable content not generally covered by web techniques can easily be made accessible as well)

a. Developers – I know that this is a broad category with any number of interpretations. In this context I mean the community that builds tools that leverage technical specifications for protocols, document formats, markup languages, application programming interfaces etc. Developers have the responsibility to leverage the accessibility functionality in those protocols, APIs etc that they leverage in a consistent way. There is plenty of great advice out there for developers, including the advice found on MSDN.

b. Designers – Designers establish the frameworks or templates for content developers to contribute to atop the software applications created by developers. (Of course one person can have all three roles). Designers are responsible for establishing frameworks or structures that simplify publishing content that is accessible across a variety of different devices. Examples of considerations for designers can be found in the W3C recommendations for Cascading Style Sheets.

c. Content creators – Content creators are the largest community since, after all, don’t we all create content? Content creators are responsible for making sure that the information that they create includes the details needed to make it accessible across the wide array of devices and format in today’s computing and communications environment. Microsoft Office 2010 includes an accessibility checker for Word, Excel and PowerPoint to help everyone create documents that are accessible to everyone.

4. Test it – Once you have created your content and are ready to publish it or send it out, test it out to make sure that it is consumable using a wide variety of tools. This might mean grabbing one or two different devices to have a look, or it might require formalized certification or conformance checking against government standards such as the US Section 508 or the W3C Web Content Accessibility Guidelines. As with any compliance review, organizations should look beyond the checklists to ensure that they have provided meaningful access to their content.

I’m sure that you’ll agree that the awareness, understanding, create and review processes listed above fit well with the normal content creation process and so won’t unduly impinge on the regular day to day routine. Just some small extras that will help you reach the broadest audience possible, be they the person next to you on the plane reading their mail when their device should be safely stowed or that other person having it read aloud to them.

Share

Tardy

Time flies when you’re having fun. I just noticed the date of my last post and realize that I have missed my goal of weekly posts by a long way. In my defence, I have been criss-crossing the globe working on some pretty exciting stuff. Open Gov, Gov 2.0, Cloud Computing, Accessibility, Privacy and Identity Management all with a distinctly Canadian approach. What’s great is that there is a tonne of Canadian thought leadership to share. The many successful CityCamps and the innovative OpenData apps that have developed from them, the real world identity management deployments underway in provincial governments and the world wide thought leadership on privacy are all of great interest both locally and worldwide. While each of these subjects deserves its own extended post (and even subject tag) which will come in due time, I was thinking about how these subjects come together and relate to one another. Certainly we could stack rank them to look at which of the themes are really just supportive of the higher order themes. That would leave Gov 2.0 at perhaps the highest level with open gov as an enabler supported by cloud computing and identity management with accessibility and privacy as key requirements. This ranking might not seem entirely useful at first blush and we might even quibble about ordering of which topic supports the others but is does start to highlight a framework for successful delivery of any of the individual subject. It could be that my security engineering is boldly peeking through, but it struck me that the defence in depth structure actually applies to most of these difficult challenges. So in place of defence in depth, it makes sense to use Design in Depth or Deliver in Depth. Successful projects consider the Principles, Policy, People, Process and finally the Products. This design in depth approach against service delivery opportunities helps connect business and service delivery leaders with those delivering the technology. It assists with the allocation of requirements and helps ensure that the right tools are used for the right things in the right way. The framework works for both a centralized and decentralized approach to service delivery as well. Many service delivery leaders are looking to the community to help deliver innovative solutions. Design in Depth helps establish the centralized vision that guides and directs the distributed empowerment to set “the Crowd” in motion to deliver solutions in support of an organization’s business objectives. While there are many examples of this, you can see this first hand in many of the municipal open government activities. The municipality typically establishes their vision (principles (and supporting objectives)) from which both the internal and external community develop and provide meaningful solutions. This distributed empowerment compliments those traditional rigidly structured projects. This complimentary relationship may well strengthen over time to an iterative approach where externally developed applications are integrated into the internal application development lifecycle. As organizations look to meet their service delivery imperatives, the Design in Depth approach allows them to connect their business leaders with both their internal development teams as well as crowd to contribute innovative solutions and approaches to meet their program needs.

Share