Friday, May 26, 2017

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 :).

Thursday, May 25, 2017

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). 

Before picture of the W3C example site
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.

After picture of the W3C example site
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.

Wednesday, May 24, 2017

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/


Tuesday, May 23, 2017

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.


an example of page source showing the DIV's used to construct the page layout.
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:
View Source showing the TESTHEAD navigation links



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.

Monday, May 22, 2017

In a Manner of Speaking: 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.

The song title puns continue, but this was a stretch. I know this one from Martin Gore, but it's a cover of a Tuxedomoon song. You're welcome ;).

22. Learn why semantic HTML is important.

Put simply, Semantic HTML goes beyond the literal markup of an HTML page and uses tags that have meaning in and of themselves.

To borrow from W3Schools explanation of semantic elements:

A semantic element clearly describes its meaning to both the browser and the developer.

Examples of non-semantic elements:  "div" and "span"  - Tells nothing about its content.
Examples of semantic elements: "form", "table", and "article" - Clearly defines its content.

Examples of Semantic HTML elements as seen on W3Schools site.
Examples of semantic HTML elements (W3Schools).

HTML 5 has taken this a step further by making it possible to structure documents by using more readily understandable terms. Tags such as "article", "aside", "details", "footer", "header", "nav", "progress",  "mark", and "time" all give clues as to what the element is meant to represent, much more quickly than a general "div" or "span" will tell you.

By using Semantic markup, we don't just make pages that are easier for users to understand, we make pages that are easier for developers to understand as well.

Sunday, May 21, 2017

I Feel Like I'm Invisible: 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.

Bad song lyric puns continue, with apologies to Alison Moyet ;).


21. Look for invisible keyboard focus when tabbing through a page.

First of all, what exactly is that? It means that we have spots on the page that do not allow us to select items or don't give us any indication as to where on the page we actually are. 

Here's a quick example. Since I figure it's only fair to call out stuff that is mine or that I actively use, let's look at the TESTHEAD site again.

If we look at the first picture, we see that I have tabbed over the element that features the Twitter link. As you can see, it has a highlight around it to show the keyboard focus being over that element:


Let's press the tab three times so that we can highlight the G+ element:


Notice anything interesting? The G+ element has no highlight around it. Let's see what happens when we turn on VoiceOver:



VoiceOver creates its own keyboard focus element, and we see/hear the words stated when we are tabbing through the document. Turn off VoiceOver and there's no indication that G+ is selected. If we press Enter while we have tabbed to the G+ element, even if we don't see the highlight, the element is where the keyboard focus is, so pressing Enter brings up the G+ dialog.

There you go, a simple example. You might be saying "OK, but so what. Just turn your screen reader on and problem solved." Do you want to have a screen reader on all the time? If you aren't a person with low vision but have a motor disability, do you want to hear that voice all the time? More to the point, what if you look away for a bit and need to get back to the keyboard, do you know where you are? Sure, you can Shift+Tab and then Tab again to get back to where you are (a process I do very frequently for this very purpose), but it's not something I look forward to. Plain and simple, if we have an option to highlight where we are on the page, do so. If something doesn't get highlighted that should be, raise attention to that fact. 


Saturday, May 20, 2017

Checking the List: 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.

20.  Write a Simple Accessibility Checklist

I don't like claiming work as my own that I've used from other sources, so I'm going to level with you. My checklist has already been compiled and it's here:

https://www.wuhcag.com/wcag-checklist/

Why this list? I like it because it takes Accessibility in three tiers (A, AA, and AAA, or Beginner, Intermediate and Advanced). To borrow from Wuhcag's page:

"Wuhcag is all about holistic web accessibility – that means taking everything about your website into account. That’s why I don’t rush you to make every web accessibility change at once – it’s too much for you to do and so it’s bad for your users. I love a structured approach to everything in life, and your website is no exception."

Each level allows the user to consider a broad range of "what if" questions. Many of these could be automated, but many of them definitely need some personal observation. Remember, it's not enough to say that a site is "compliant". It's more important that the site is usable and can provide an experience for the end user that would be comparable or in line with what a normative user would experience.

Does that sound like a challenge? It certainly is, and it means that there will be lots of opportunities for human interaction for at least the near future. Not sure what to look for or where to direct your efforts. The above three checklists are certainly good places to start.

Some Cool People To Follow on Twitter: 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.

19. Find 5 accessibility experts to follow on Twitter.

1. Albert Gareev (@AGareev): Albert and I have been friends/compatriots/writing partners/co-presenters for seven years when I made the commitment to get more involved in the testing community in the first place. It turned out that Albert was also actively involved in Accessibility, and thus, when I started working on it as part of my work, Albert became a lifeline of ideas and encouragement. We've worked on several things together, and the "HUMBLE" mnemonic is rightly his, though both of us present it.

2. Alicia Jarvis (@AJarvis728): Alicia has likewise been active in the Canadian Accessibility community along with Albert, and has been a source of advocacy, passion and focus that I've reached out to many times. My first association with Inclusive Design and thinking about it was because of her tweets and advocacy.

3. Ellen Parfitt (@deafieblogger): Ellen is a new one for me, in that I came across her work during this challenge. Her site HearingLikeMe.com has a lot of great insights dealing with hearing loss and working with technology to enhance the experience for those with hearing loss (both primary and incidental).

4. Neil Milliken (@NeilMilliken): Lots of stuff I could point to for Neil, but the AXS Chat Community is a good enough place to start :).

5. Alice Boxhall (@sundress):
 Another recent discovery during this 30 days challenge. I've enjoyed learning about her and the initiatives she takes part in.

There are of course much more, but if I were to name all of them, we'd be here all day. Start with these five, read what they have written and commented about, and who they interact with. My guess is you'll discover a lot of people worthy of your time and attention.

Thursday, May 18, 2017

A Certain Shade of Green: 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.

18. Use a tool to test for colour contrast problems.

It seems I'm giving WebAim a lot of love this month, and there's a reason for that. They do a good job of taking Accessibility concepts and breaking them down into hands-on tools that a user can play with to understand what they are looking at and ways to play how-to scenarios with them. WebAim's Color Contrast Checker fits squarely into that niche as well.


The Color Contrast checker needs two values, a background color & a foreground color. You can choose any of the hex values that make up a color code and either enter them into the two text boxes provided, or you can enter them into the URL directly like so:


The resulting screen will display the values, and then give you options to lighten or darken the foreground and/or background, and see both the Contrast Ratio as well as what the contrast would look like on a page if it were used.

As we can see, that's not a really good ratio, and that would be hard to read even for normative vision users. 

Let's adjust those values to something a little more reasonable, shall we?

By clicking the Lighter/Darker links, we can change broadly the shade that is selected. By clicking on the actual text box, we can bring up a color picker and choose a color that we like:


The color picker gives you two regions. One gives a large selectable color palette, and the other provides an arrow slider so you can select the level of saturation for that hue. Regardless, the end result is a hex value that is represented in the corresponding text box. With that, you can see if your contrast level passes, and the contrast ratio value.

What's this useful for? If you are responsible for reviewing CSS or otherwise determining contrast levels for text, backgrounds, widgets, etc. This allows you to look at corresponding colors, experiment with variations, and see what works both aesthetically and numerically. Granted, it's not going to let you look at your pages directly (there's other stuff for that, and I'll post links later in the challenge) but for now, if you want to get your feet wet, here's a good place to start.





Wednesday, May 17, 2017

What Are Words For? 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.

17. Find a problem that might affect someone with dyslexia.

I have to confess, I struggled with trying to understand this before this month's challenge. That's often the case with normative users in regards to [fill in the blank] normativity. It's one thing to try to empathize, but the frustration just isn't as easy to relate to if you don't have a point of reference. Vision problems weren't frustrating until I developed my own near-sightedness due to advancing age and determined that my readers were much more than a handy fashion accessory, they were essential to my daily operating. Hearing loss I have a little bit more to work with, as I have approximately 30% hearing loss from a decade-plus playing loud music (kids, wear earplugs when you rehearse and perform).

Dyslexia I struggled with trying to understand because reading is one of my big loves of life. I've never struggled with reading for comprehension and so I wasn't sure how to really internalize this one. Then WebAim decided to put something together to both humiliate me and make me see a problem anew, as well as what I could do about it.

First, let's talk humiliation... WebAim has a dyslexia simulation you can run on yourself.


Through a basic introduction to some of the hallmarks of dyslexia (letter reversals, word reversals, inversions, transpositions, word confusion and spelling inaccuracy) there's a lot to consider when looking at dyslexia symptoms and then realizing there is no "one size fits all" option. Each person has a differing set of symptoms and degree of severity of some over others. Still, we have to start somewhere, so how about here:



So... how did you do? Truth be told, it took me three read-throughs, and a bit of de-focusing to be able to get that to flow together to understand it. After the read through, it asks you two questions. I'll let you all go there and see if you can answer them, but basically, there are several things we can do to improve the readability of pages (and several modifications I should be making to my own blog here):

Consistent Navigation and a spare layout help a great deal with a predictable and easier to comprehend interface. Nesting and sub listings are not helpful and could potentially cause a dyslexic reader to lose track of where they are and what they are doing.

Chunk text and pictures in a way that makes the process of reading a site less daunting. I admit I'm guilty of this because I have a tendency of being a wordy fellow. Grouping text under logical headings and making more use of bold section lines to differentiate various sections would be a big help.

Context Matters, and therefore, if pictures can help you tell your story or make a point/help achieve an objective, by all means, use them.


Consider how your page would look if it were printed. People with dyslexia may wish to print off a page to read it in their own time and at their own pace.

Allow the user to control the layout and size of media they see, where possible.

As in the other posts about "find a problem" that holds true again, is that the simpler and cleaner we make an interface, and as we structure our pages to be modular, small amounts of text grouped in areas with titles that stand out, we improve the experience for those with dyslexia and for those who don't have it. Simple and spare design helps improve the usability for everyone, so design with that in mind up front :).