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


Tuesday, May 16, 2017

When You Can't Get a Grip: 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.

Yay! I'm all caught up :).

16. Find a problem that might affect someone who can’t use their hands.

This is a broad range of issues that falls under the umbrella term "motor disabilities" and can have many possible causes. We can be talking about the limited use of limbs due to paralysis, deformities, prosthetics, and in cases where there is no limb to use. Due to these limitations, there are several instances that can be looked at as barriers to interacting with technology, as well as a number of devices that can help with overcoming those limitations. 

I remember as a child seeing a news program that celebrated a local resident who had lost the use of her arms due to an accident. She was a talented artist, and rather than give up her skills, she trained herself to use her mouth and her head movements to replace the motor control that her arms and hands used to provide. Yes, for those curious, she resumed painting by holding a paintbrush in her mouth. In many ways, that analog is used today by many with motor disabilities, where the head and neck, eyes, chin, and mouth are utilized to make up for the loss of hands as primary input devices.

WebAim has a page that is dedicated to assistive technology alternatives for those with motor disabilities. These range from simple sticks that can be held in the mouth to adaptive keyboards and large trackball mouse devices to speech recognition software. As someone who does a lot of typing throughout the day, I would find it particularly challenging to try to interact with a computer system sans the ability to type. Voice recognition software can come to the rescue, but that's also provided that you have a clear enough speaking voice to be able to control the software to respond correctly and effectively.

Have we noticed a trend in these past few posts? In all of them, I could make some specific recommendations, but there's one that stands out as near universal. Systems that are simply designed, with a minimum of clutter, are going to work better for anyone with a significant disability. What's more, a simpler and cleaner design will not just help those with disabilities but will be more helpful to everyone. Also, the last big takeaway from the motor disabilities page is that most devices mimic or interact with a keyboard so we would do well to make our products as keyboard friendly as we can, and in the process, require as few keystrokes as possible to accomplish the tasks we need to.

In Sharper Contrast: 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.


I was away much of this past weekend, so I'm going to need to double up a couple of entries for a few days to catch back up. Thank you for your patience :).

15. Find a problem that might affect someone who is colourblind.

I have actually had a chance to interact with one of my scouts over the course of the past few years who is color-deficient and who has shown me several times how some sites are difficult for him to read because of the lack of contrast. His particular color-deficiency is called Protanomalia, so he has difficulty with seeing red or colors in the red spectrum, but it's not as pronounced a deficiency as Protanopia, which is a virtual loss of red perception. Still, even with a red deficiency, that often makes sites or apps that use red and that use colors that overlay the red as difficult to see. Thus, for me, the takeaway is that contrast is more desirable than aesthetic sense. 

I recently went back and looked at my blog and noticed that the gray to white contrast was not very strong, and after playing with my site in some color contrast tools, I decided to up the contrast and trade out orange elements for a brighter yellow hue. this matched wth white text on a dark gray background passes the first level of contrast, but I still have some issues regarding higher end contrast. 

Anyway, enough of my blathering. You probably wondered if I'd provide a resource that could help you look at color and color deficiency in a different way, right? Here's hoping I deliver on that promise. Visibone has a page dedicated to "Color Deficient Vision" and some examples to help you make choices regarding colors and color contrasts.


We're Not All Ears: 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.


I was away much of this past weekend, so I'm going to need to double up a couple of entries for a few days to catch back up. Thank you for your patience :).

14. Find a problem that might affect someone who is deaf.

I've already addressed this somewhat with talking about how The Testing Show offers transcripts of our shows, but I wanted to think about this a bit deeper. I mean, that's great and all, but am I really looking at a big picture here? How else are we inadvertently not allowing those who are deaf to completely take advantage of the web and mobile apps?

In my poking around, I found "5 ways to make websites more accessible for deaf people", and in it, they list a few areas I really hadn't considered, i.e. they go outside of what I typically think about:

If your contact info doesn't have multiple options, or you just list a phone number, that's certainly going to be a problem for a deaf/hoh person. In this day and age, it may seem odd to not include an email, but many sites don't. The more options allowed that let people see and type in their inquiries, the more likely they will interact with you.

Subtitle/caption for videos: Seeing as I am currently creating a podcast that uses YouTube as a delivery mechanism, it's pretty nice to see the Closed Captioning option and how it works. It misspells my name, but I'm used to that ;). Other than that, that's a great plus, so if you want to use YouTube for video content, their CC option works well.

Using Simple English, or doing our best to make our message as clear and consistent as possible makes it possible for ASL communication to be less fragmented. Keeping it simple becomes even more important for people who may not consider English their first language (i.e. ASL would be).

Using Social Media channels to help communicate is a new one for me. I hadn't considered that using services like Facebook or Twitter, by the developed familiarity that people have with those platforms, can help amplify a message or a service by using the social platform paradigms.

Streamlining Navigation is a big plus for users who are blind or with low vision, but deaf/hoh users likewise benefit from a simple to navigate site. This is an example of Inclusive Design ideas coming into the discussion, where principles for one community can help make services more usable by everyone.

My thanks to Ellen Parfitt for the original post and some things to think about :).