Planning for Accessibility: Accessibility for Everyone: Long Form Book Review

Continuing on, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

PLANNING FOR ACCESSIBILITY

One of the scariest propositions is to be told that Accessibility is now a prime focus of your work, and your product needs to be retrofitted to be accessible. Still, that's a reality a lot of products share. To make a product truly accessible after the fact almost always requires some focus and attention (by way of example, my current company did an Accessibility audit five years ago, and the resulting work required to fix the issues found took fifty stories to complete). Designing with Accessibility in mind from the start makes things easier, but you will likely have to do some convincing. To do that, focus on the ability to navigate your site as easily as possible, make the point that it will give your product a competitive edge in the market, explain that having an accessible design will likely lower your support costs because an Accessible design would help overall UX, and it will help protect you from being sued.

The next step, of course, is to make sure that you have the right people on the team to do the work. You don't have to have Accessibility experts on your engineering teams, but you will have to come to grips with the fact that Accessibility is more than just checking off requirements in WCAG. Accessibility is best addressed when the whole company gets onboard with the approach and designs with Accessibility in mind from the beginning. Those skills take time to master and they may well be slow going for awhile. Laura does right by addressing this. Yes, a programmer can learn about the various tag structures and can create automated tests to verify they exist. That's a good start, but if we are not actively making sure we are making products that are genuinely useful to those who most need it, we're missing the point.

Using my own project as an example, we started out with a list of things to fix. We devoted two engineers and one tester (me) to see the changes through. Over time, we grew to understand what the changes would actually entail, and that it was not going to be an easy or quick fix. The resulting story work took the better part of a year to complete and we all learned a lot in the resulting year, both in the way of what the code needed and what to test for. Fact is, this was driven by a large client that was willing to buy a lot of software from us, so it was very much worth it to us to do the work. For organizations without that immediate incentive, it may be harder to convince people of the need. If you know the resulting revenue will outweigh the development costs, it's easier to go in and do what you need to. If the payoff seems distant or completely nebulous, it's a harder proposition to sell. This is where research comes in, and research means getting real users with real issues and real pain points to talk with you or share their experiences, or for you to recreate those experiences. It may be impossible to delve into every possible option, but even getting just a few different people's perspectives can tell you a lot. However, it is important to realize that, while you can get a lot of insight from a few people, it would be unwise to base all of your decisions on just those few people. Just as any one person will not be truly representative of a whole population, individuals with disabilities are just that, individuals. They can provide insights, but they will not provide all of the insights you may need.

Once you have determined the scope of the work, you will need to prepare for testing using tools that will help you accomplish your goals. get familiar with the Accessibility settings on your various systems. Use the screen readers that are available. Use the applications that are voice-driven and spend time getting good at using them. Many technologies that are available will be free or cost very little to implement. Some will cost more, especially physical devices.

Perhaps the most important things to realize is that Accessibility is not a one-off project. Once you determine that you are going t make Accessibility apriority, it becomes a part of your overall design process. That means that each and every story being developed needs to have an Accessibility discussion and ways to verify that you are designing for that purpose and testing to see that the purpose is being met.

KEY TAKEAWAY

Laura spells out the reality of making Accessibility a priority, and she uses a number of additional resources to support why this is important (want to know what those are? buy the book ;) ). Already, I can appreciate that, early on, Laura is pointing out that Accessibility is equal parts good design, solid engineering and quality practices, and continued advocacy that will go on long after the major heavy lifting to implement Accessibility has been completed. Without continually revisiting Accessibility standards, and making it a core part of your development and quality philosophy, you may find yourself having to rework many parts of your code again later.

Disabilities and Impairments: Accessibility for Everyone: Long Form Book Review

As I mentioned yesterday, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

DISABILITY AND IMPAIRMENTS

One of the misleading aspects of Accessibility is getting a handle on exactly who is impacted and how many people that actually is. We look at disabilities and impairments as a single issue and try to address them when it is often the case that many people don't just struggle with one accessibility issue but with several. Vision, hearing, mobility, and cognitive impairments can run a spectrum from mild to severe/total in people. If we look at the US, nearly 38 million people deal with a disability (12% of the population). 16% of people in the UK have a disability. I personally have been dealing with impaired vision over the past few years, which is normal for people of a certain age and older. With my readers, I'm basically a normal computer user. Without my glasses, I now struggle mightily to make sense of what I'm seeing.

Language is important here. "Being disabled" speaks with a sense of finality, while "has a disability" means it is an issue a person deals with but it doesn't define the totality of who they are. Laura emphasizes this latter terminology, and I think it's a good approach. It helps eliminate the idea of disabled people being something other than or outside of ourselves. If we address Accessibility as something everyone will have to come to grips with at some point, it's easier to consider and plan for development, because we've framed the discussion as we can all expect to "inhabit the disability" domain at some point.

It helps to consider what disabilities we might be in for at some point. Laura makes an excellent breakdown of a variety of issues that people deal with in the disability sphere. Color blindness varies and shows up in men 16 times more frequently than it does in women (yes, women can deal with color blindness, too). Eyesight loss can be caused by many different things and can range from afflictions like glaucoma, cataracts, macular degeneration, astigmatism, etc. Auditory impairment can come in different flavors as well. There's total hearing loss, which has a number of causes, and gradual hearing loss, which is more common. Motor impairments can range a number of causes, including cerebral palsy, multiple sclerosis, rheumatoid arthritis, muscular dystrophy, ALS, etc. Traumatic injuries to the brain and spine can also cause motor impairments, ranging from impaired movement to total paralysis. Cognitive impairments are also an issue, affecting things like memory, attention, problem-solving, text processing and math processing. Dyslexia also falls into this area and some dyslexic users use screen readers to assist them in reading information on pages.

Laura also hits on a point that I often use when I talk about Accessibility, in that there are what we call "primary disability" and what I refer to as "situational disabilities" and what Laura refers to in the book as "environmental disabilities". The point being, you may be a normative user most of the time, but a situation occurs that temporarily makes you a disabled user. Noisy environments, having to deal with a different language, low light levels, and other environmental issues can greatly impact the way that you interact with your applications.

KEY TAKEAWAY

Statistics can be helpful, but they don't tell the whole story. We do much better when we can humanize the situation, and get into the worldview of our users, whoever they may be and whatever issue(s) they may be dealing with. By understanding the possible range of issues, both primary and situational/environmental, we can get a better understanding of how and where we can address Accessibility issues.

Accessibility for Everyone: A Long-Form, Multi Part Book Review

One of the things I find frustrating about technical books is that I often use them for a period of time, get an insight or two, go off and work on that insight for a while, and then I put the book down or look at something else until I'm in the mood for another insight, and the process repeats. Much of my technical library gets used this way. As such, I have hundreds of books that I have read part of, dozens I have read all the way through, very few that I have read cover to cover in a short period of time.

That makes it difficult to do timely reviews for certain books, so I decided I wanted to change that. Therefore, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. Some may remember my chapter by chapter breakdown of Alan Page's book "How We Test Software at Microsoft" or Zed Shaw's "Learn Ruby The Hard Way". I'm planning on doing something similar this go around. However, this is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book. It's officially available as of today :).

All right with that out of the way, let's get into it.

ACCESSIBILITY FOR EVERYONE

Let's start with Heydon Pickering's Foreword. For those not Familiar with Heydon, he is the author of "Inclusive Design Patterns", another book that I want to do a proper review for as well. He points out that dealing with Accessibility is a step out of the comfort zone for many, and admittance that we have, at times, not been kind to some of our users and also to acknowledge that people use their technology and the Internet differently. By thinking and designing inclusively and considering Accessibility up front, we can better serve a more diverse group of people, and that is a worthy end goal in and of itself. I wholeheartedly agree.

CHAPTER ONE: CONSIDERING ACCESSIBILITY

Generally speaking, Accessibility and Inclusive Design don't fall into the lap of one person. There's no single arbiter that determines if a site is Accessible, and if you are part of an organization that is set up that way, let's just get this out of the way now... "you're doing it wrong" (btw, that's me injecting color commentary, Laura didn't say this specifically ;) ). Accessibility doesn't happen in a vacuum and it cannot be addressed separately from the rest of the development of your site or app.

Are there excuses to be made for why Accessibility is not something every organization considers from the outset or places great emphasis on? Absolutely. Some see it as boring, or the connection with the beneficiaries is hard to pin down. We're afraid we'll do it all wrong, and the most likely candidate for peak excuse is "it's too hard and there's too much to do". Laura hits every one of these out of the park. I'm intimately familiar with every one of these resistance statements and yes, all of them can be true, but we can also rise above them if we are so determined.

Ultimately, Accessibility is making a choice to include as many people as possible. For some, that will mean making specific modifications to communicate with assistive technology. Laura uses a simple example to drive the point home with doorknobs. Doors with round knobs are less accessible than doors that have levers that can be twisted. Laura makes the point that even her dog can open a lever handled door (though she frequently wishes that were not the case). A sliding door with a motorized movement and proximity detector to open would be the most accessible and would work for everyone, but may be impractical to implement everywhere. In this case, the lever knob is as inclusive as possible and as practical. It's definitely better than the round knob. Tones at signal crossings, closed captioning, simple and clear signs, and my personal favorite example that I love to hate, IKEA assembly instructions ;).

To successfully approach Accessibility, one of the best ways to put us into that mindset is to develop Empathy. It's easy to dismiss products that don't serve our needs when there's nothing preventing access to us. At that point, it's a matter of taste and aesthetics. However, it becomes a different issue when a product conspires to work against you because of dense text, dependence on mouse or touch controls, use of certain elements or not using them to deliberately or not deliberately but unknowingly locking people out of using them. The fact that I now have to wear readers has had a profound effect in the way that I interact with technology today.

The symbol of Web Accessibility today is the "screen reader". In fact, for many people, the screen reader is the start and finish of many Accessibility initiatives. If you mix Dragon Naturally Speaking into the mix, hey, you're off to the races. Alas, it's not that simple, and there's a lot of other issues related to Accessibility. Screen readers do however emphasize the fact that the mouse is effectively unusable, and that keyboard navigation is essential, and that is a big wake-up call to a lot of people when their mouse or trackpad isn't part of the workflow. See Empathy above ;).

KEY TAKEAWAY

Accessibility has a vocabulary all its own, and it can feel like there's a bit of an "in crowd" mentality to those not familiar with it. I admit to feeling the same way the first time I saw the #a11y hashtag and wondering what it meant. I was happy to be an ally, but then later learned that a11y was a way to say "Accessibility" in a shorter way ('a' with the number eleven between the 'y' because accessibility is 11 characters long). that's clever but it takes asking to understand what it means, and that's a bit of a metaphor for Accessibility in general. We want to make the web and apps accessible, yet sometimes getting into the "club" to understand Accessibility is harder than it needs to be. Laura is throwing down a gauntlet and saying that Accessibility needs to be something everyone on the development team has a stake in and takes part in, hence the book title, Accessibility for Everyone.

Regarding Comments and Interaction on TESTHEAD

As I've been going through the site to determine changes I want to make regarding Accessibility and Inclusive Design, I've been doing a review of past posts (with more than 1,000, this is taking awhile, but I'm getting there). In the process, I've also noticed a recent uptick in comments. At first, I was excited, but quickly saw that most of them tended to be the same:


nice blog has been shared by you. before i read this blog i didn't have any knowledge about this but now i got some knowledge. so keep on sharing such kind of an interesting blogs.

This would then be followed by a link to some other site, usually offering training of some kind.

At first, I tended to approach this with a bit of a buzzsaw approach, just deleting them out of hand, but during CAST, I talked to a friend and colleague and described my frustration with this approach. They suggested something I hadn't considered. It may be SPAM. It probably is SPAM if it is linking to a commercial link, but there is a possibility that this is also a new student fulfilling a class assignment to find a technical blog, read a post and comment on it.

Fact is, I don't know, but the better, possibly more naive part of me wants to believe that some of this traffic might be legitimate, so I'm going to make a few requests.

1. If you read something that you appreciate, let me know specifically what you like about the post. That at least gives me an indication that you have read it.

2. Ask me a question about the post. This may be a mild psych thing with me, and I may regret admitting this down the road, but I'm the type of person that, if you ask me a question in social media or via blog posts, I feel compelled to answer. My answer may be "I don't know" or "I'd have to point you to [x]" but I will answer :).

3. If you are posting a link to a site that supports or substantiates what I'm saying, or disproves what I'm saying, that's fair game. Posting a link to your training site without at least explaining why you are doing so is just rude. If you are saying "Hey, I like the pattern matching examples you gave in your post. I'm currently attending a training academy that also covers this, and you might find this useful (link to a specific example that corresponds with the blog post)", seriously, I'm fine with that.

Nonsensical praise like what's posted above tells me that you haven't even read the blog post, you want to get your link on as many of my page as possible, and will guarantee that I will go through and mow such comments out of my feed aggressively. Also, the time I have to spend chopping out bunches of bogus comment posts limits the time and attention I can spend writing new stuff.

For those who have posted informative and inquisitive comments, I thank you and appreciate the fact that you do so. For those who want to do so, but aren't sure how I promise, I'm a rather wordy fellow who is happy to answer questions and do not mind sharing links of a genuinely informative nature. Let's make this a place where we can communicate ideas and not a jumble of SPAM comments that I have to consistently prune.

Getting Ready to CAST a Wide Net in Nashville

It’s time to get back in the saddle and start doing some live blogging and somewhat real-time podcasting. Now that CAST is this week in Nashville, I’m doing my last bit of planning and logistics to get me to Nashville and get ready for CAST. For the past couple of months, Claire Moss and I have done some teaser podcasts for the conference (dubbed the AST CASTcast). If you haven’t been following along, here’s the whole series we've produced thus far (we have 18 episodes you can listen to :) ):


I will be Live Blogging this conference, but in a change from the past, I will not be doing it here on Testhead. AST has asked me to do my Live Blogging directly with the conference materials, so I encourage everyone to follow along over at the AST site.

With that in mind, I’d like to do an experiment. There are many sessions I would like to attend, but since I’m live blogging the event, I thought I would throw out to the readers of Testhead… what talks would you like to have me attend? What topics interest you? What do you think I might benefit from tuning into that may not currently be on my radar?

Also, I will be packing my microphone, so if you would like to have us record a podcast or two while we are there, let me know who you would like to interview and we can see if they would be game to participate.

It’s going to be an active week. I hope you all will follow along with me, and yes, I will also post some here as well :).

Wrapping It Up: 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

Yes, it's past May. In fact, it's June 5th. An extended absence for Memorial Day weekend turned into a frantic last week of school for my girls and my having a lot less time to finish strongly, however, a promise is a promise, and I said I was going to do all 30 days, and I'm gonna' cover them all. Therefore, today, you get a "fourfer" and a wrap-up commentary all in one.

27. Learn how to use your mobile device screen reader.

Since I have an iPhone, this is fairly straightforward. iPhone has VoiceOver, and to enable it, you go to Settings: General: Accessibility: VoiceOver.

VoiceOver presents you with a few options to configure, such as:

- VoiceOver speed, which can be slower or faster with a swipe.
- Use Pitch change
- Verbosity: gives you an option for speech hints and to also read out emoji content.
- Voice: select a speaker whose voice you want to hear (you have a few defaults, and you can download other voices as per your preferred gender and accent).
- Pronunciations: If you want to make sure that you have certain words pronounced the way you want to you can create a custom phrase.

The biggest challenge as a sighted user is that the system slows you way down and forces you to select an area, listen to what it is and then press twice to enable that area to do something. Using the keyboard is slow because every key stroke is effectively three steps. First to locate the item and confirm that it is the item in question, and then two taps to make sure that the item has been selected. Even with full sight, I found it frustrating to type in a simple statement. I couldn't imagine keeping track of what I was typing if I was sight-impaired.

In any event, it's an interesting piece of tech and there's quit a few areas I ned to still look at to really get a feel for what it can do. More to play with after the challenge is over (which really, means later today ;) ).

28. Download and test a word document for accessibility issues.

I was hoping this would be an easy thing to test since I trade Word docs back and forth to get the show notes for The Testing Show completed, but alas, it seems that my documents are not interesting. Therefore, I figured I'd find a document somewhere interesting enough to give me an example to work with. I found "Word 2010 Accessibility Guidance - GSA" which let me do exactly that:

By clicking on Review and selecting the Accessibility Checker button, I can see in a preview window areas that can be improved. Interesting enough, a document based on 508 Accessibility Guidelines for Word Documents could use some Accessibility help. Well, I found that amusing.

29. Find 3 accessibility issues without using an evaluation tool.

Time to pick on Blogger again, or should I say, time to pick on TESTHEAD again ;).

1. Should have a default skip to content link in the tab order as soon as it enters the page. May have to hack my template to make that happen.

2. Numerous images going way back need alt tags. That's my own fault and will be a long process, but if I'm serious, I best get to it, eh :)?

3. Since I'm doing this without a tool, I am looking at the background for my blog (dark gray) and my text (light gray). It may be conformant, but I think it should be more pronounced than it currently is. 

This month's challenge has been interesting in that I was able to come up with those with less than 30 seconds of looking at the page. OK, I've been focused on it for an entire month, but from thinking my site wasn't too bad to be able to think that quickly about what could be improved, not a bad return on investment, in my humble opinion :).

30. Review the complexity of a website’s content with the Hemingway app.

Awww, this is a pay-for app. Nothing against that, but since this is a blog post about a daily challenge, I don't want to specifically purchase an app just to qualify it (at least not just yet), plus I'm already a paid Grammarly User, but Hemingway does offer a "write" option to test it out, so I'm going to take my last full blog entry and see what it says:

OK, so that tells me that "therefore" is a bit stuffy and I could use a simpler word, I have a big sentence that could be cut down a bit, and I can make the page more readable, but as it is it's readable at a 5th grade reading level, and that's cool with me. Always room for improvement, but I don't want or expect my writing to require an English degree to decipher.

Wrapping it All Up

Wow, this was an eye-opening month, and this is coming from someone who professes to be an active Accessibility Tester. My thanks to the Dojo for putting this challenge together and giving me a chance to consider anew what I can do to better test for Accessibility and Inclusive Design. 

So what's next? A  few tools are going to get a documentation treatment for my internal testing pages for my company, and even more important, I'm going to do some digging to figure out how to hack my blog template to qualify for WCAG 2.0 AAA rating. I've made a few changes to it this month, but there's plenty of room for improvement, and therefore I should be busy with this challenge well beyond my tardy week past May. 

For those who have read along, I thank you. For those who have taught me much this past month, I thank you even more. For new friends I have made through this challenge, thank you for your patience, your consideration and opening my eyes to ways I can both test better and be a better advocate. 

It's been fun, and I look forward to the next "30 Days of Testing" challenge, whenever it may be. 

Spread the Word: 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

26. Find an accessibility issue on a website, and report it.

Since Blogger is my tool of choice for hosting TESTHEAD, it seems only fitting that I look to it to see what I can do to help improve its ability to be a better accessible platform or, barring that, at least accessible as far as what I can actually do to enhance it.

Using WAVE, the following error was the first to pop out:

Errors

Document language missing

What It Means

The language of the document is not identified.

Why It Matters

Identifying the language of the page allows screen readers to read the content in the appropriate language. It also facilitates the automatic translation of content.

How to Fix It

Identify the document language using the attribute (e.g., ).

The Algorithm... in English

The attribute is missing or is empty.

The nice thing about Blogger is they have a "Send feedback" button in the lower right-hand column for the Dashboard, so submitting issues is easy, as well as with screenshots.

Curious to see if in the future we see this enhanced :).

Shapes of Things: 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

Taking a brief moment in this post to reflect on a milestone. Thank you to everyone who reads TESTHEAD. This morning, my one millionth visitor came to this site. I wish I could figure out who that person is, but regardless, I want to say thank you to everyone who has come here over the years, whether it be one time or repeat reading.

25. Explore W3C’s Before and After Demonstration

The subtitle for this page is "Improving a Web site using Web Content Accessibility Guidelines (WCAG) 2.0", and I have to say, this is a nice little resource to see because it gives you some concrete examples of what you could/should do to make a site accessible.

Here are two pictures of the home page they use for their example (there are several pages with before/after examples). 

Here's the "Before" picture example. Notables are the headings for the pictures and the phone number at the bottom only using a hip word spell out.

Here's the "After" picture example. Other than some cosmetic variations on the layout, notable changes are having more meaningful headers for the image blocks, and the phone number displays both the digital version and the lettered mnemonic.

What' nice about this example is that you can put the two pages side by side in two separate browser windows and just by looking at the two, you can see why the After picture would be preferable.

If, however, you want to see what can be improved and what was applied in greater depth, each page has annotations to show exactly what needed to be changed and what change was applied. The top nav bar can quickly toggle between Before/After to see what has been changed. 

If you have been curious as to see how cumulative changes can be applied and the rationale behind what they are, then have a look at the Before and After simulation.

What is the Law? 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

24. Learn about accessibility law in your country.

I live in the U.S.A., and therefore, while WCAG 2.0 is the guidelines I aim for, we usually refer to "Section 508" or features being "508 Compliant" because that is a section of the Rehabilitation Act of 1973. Actually, there are two areas in the Rehabilitation Act that relate to disabilities. The first is Section 504, which declares that the act "prohibits federal agencies, programs, or activities from discriminating and requires reasonable accommodation for qualified individuals with disabilities." Section 508 declares that "agencies must give disabled employees and members of the public access to information that is comparable to access available to others." A basic checklist of Section 508 compliance can be seen by clicking on the link.

Notice anything interesting there? Did you see anything mandating that Accessibility is the law everywhere? Nope. Just in the services and the fund allocated for them by the federal government. Is there a strict standard? Again, nope, but Section 508 by virtue of being a policy of the federal government, and with the sheer volume of software seats that the federal government provides, can carry a lot of weight in regard to the design decisions of companies.

I know for a fact that a large agency of the federal government looking to purchase a lot of software from my company was what initiated a thorough review of Accessibility requirements and areas that needed to be updated in our product so that they would buy it. The dollar amount of that deal most certainly played a part in why we undertook a large-scale retrofit of our product to meet Accessibility standards, and again, the standard we measured for that purpose were the guidelines as described to meet U.S. requirements. To meet the broader WCAG 2.0 requirements means we still have a distance to travel still.


For a nice breakdown of what USA Laws do and don't cover, see http://webaim.org/articles/laws/usa/

Mental Hopscotch: 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

23. Find missing semantic information (e.g. headers, landmarks, links, and buttons).

Yesterday, we had a look at Semantic HTML and what it is. Today, let's take a look at how well my blog actually uses it (yep, we're picking a fight with TESTHEAD once again :) ). That means, indirectly, I'm also calling out Blogger as to the way it lays out its pages since TESTHEAD is hosted on Blogger.

As I open the source and try to see what each page would be showing me, the fact is, most of the layout for Blogger is not using Semantic HTML in any easy to see manner. Almost everything is a div, with a hierarchy in CSS that is a bit hard to decipher on first glance.

A quick look at the div listings. They are named, but not using the examples highlighted yesterday.

Here's a look at the navigation section, which does use a header tag:

Granted, Blogger is a template system, and there is a lot of manipulation required to make those templates work with individual customization, so a semantic design may be difficult to pull off, but I wonder if I could work some of the options into my individual posts. I will give it a try tomorrow for comparison.