Taking an AXe To It: Starting Accessibility Tooling (#CNC2018 #BLOGMORE)

I am rather far behind with my commitment to the #BlogMore challenge in the #CNC2018 campaign. Part of that is, of course, “life is what happens when you are busy making other plans” but more specifically I came to a conclusion that my original outlines were way too ambitious.

My topics as outlined were more suited for chapters for a possible book rather than single blog posts. Thus, I have decided to take something from each of the outlines and get very specific. Rather than do a vague post about Accessibility and Inclusive Design, I will focus on a specific tool that will allow me to address coding and design more directly.

There are numerous tools available that will allow programmers and testers to evaluate websites and applications for Accessibility and Inclusive Design. This post will be about just one of them. aXe is a tool developed by deque. It is open-source, free and runs inside of the browser along with a variety of Developer Tools. Currently, two versions are available (for Chrome and Firefox).

Adding an aXe to Your Arsenal

Installation is straightforward. Start by navigating to the download page for the extension (here’s the flow for Firefox):

1. Click on the Add to Firefox button.

2. Give aXe permission to be added as an extension.

3. After installation completes, this confirmation screen will appear.

4. Depending on how many add-ons you have, you will see something similar to the following on your Firefox browser toolbar.

5. Click on the aXe icon to get a help message. aXe is part of Developer Tools and appears within that context.

My preferred way to open Developer tools is to just click anywhere in the browser main window, right click, and then select “Inspect Element”.

If your installation went correctly, you should see the following. Click on the aXe navigation bar header to see the screen below. If you see this, you are good to go.

Press the “Analyze” button on your chosen web page. I might as well pick on myself. Let’s have a look at http://mkltesthead.com/.

See that output at the bottom? That’s an indication that I have some stuff to deal with.

I hear you saying, “well, OK, that’s… interesting… what exactly am I looking at here?”


A First Pass at your aXe Analysis
aXe gives the user a condensed listing of issues found. Let’s take a look at the listing in more detail:

The top section displays the number of Accessibility violations (in this case, 95 of them). The listing below the violations count is an area that says “Needs review”. These are potential violations, but they may not be. Let’s take a look at one of them:

We can see the issue. The validator cannot actually determine if the color contrast of the title is compliant. The reason is that there is an image beneath it, and that image has varying shades, where in some areas there is definitely a bold contrast, but in a few areas, the “whites of the Tachikoma’s eyes” are right next to the text. Below the issue description is the actual code that is being evaluated.

In this case, I have two choices. I can either tell the system that this is not an issue and move on, or I can consider how to match both the letter and spirit of the issue and fix it. Options are I could remove the image, or I could darken the image significantly so that all areas are in sharp contrast.

Additionally, I can do some sleuthing through the tool by clicking on the “Learn more” link next to the description. I can also click the “Inspector” link and see the element in context with the surrounding code for the page:

Clicking on “Highlight” will focus on the element in question but leave us with the review screen:

Having given the code a once-over, I can now (if I choose) make a decision for a course of action. In this case, I am going to make the executive decision to leave the image as it is and say that it is “not an issue” because, for 97% of the text, there is ample contrast.

By selecting “This is not an issue” and clicking the “Save” button, I update the aXe database and move on to the next issue that needs review.

If you followed along, that should give you some feel for how you can quickly use aXe to validate a number of Accessibility issues on your chosen page. There's plenty more where that came from, to say the least, and I will be getting into more details in future posts, both with aXe and a few other favorite Accessibility tools.

Code Newbie Challenge 2018: #CNC2018 #BlogMore: Mission One: Blog Ideas

The first official mission for the Code Newbie Challenge has completed. Here are my follow-up and thoughts about this week's assignment.

Mission 1:  Three Ideas

Goal
Develop and validate the three blog ideas for this challenge.

Homework 
Come up with 10 blog ideas, then narrow those down to 3.

This challenge had a lot of great supporting material to help people get into the mindset of what it would take to create a technical code blog post. 

Research: 

• Search Twitter for hashtags related to areas of interest.
• Search blogs that talk about areas of interest. Medium, Dev.to, FreeCodeCamp, Hackernoon, Codeburst, basecs, Mozilla Hacks, etc.
• Look at Newsletters like JavaScript Weekly and RubyWeekly
• Think about things I am actively working on and wish there were posts that answered my concerns.

Brainstorm:

Aim for ten ideas. Here's the list I came up with:

1. Examining Accessibility and Inclusive Design (this is my personal touchstone topic, as if I really want to make a transition to writing code, I want to do it in a way that can help me advocate for Accessibility and Inclusive Design better) - Explainer for concepts, tutorial or project for specifics
2. Walking through Developer Tools that emphasize Accessibility - Explainer
3. Making a Skeleton Resource for Coding (my biggest problem is getting started, so my overall goal is to make something that will help me do that. I figured I could explain along the way as I make it). Project, possibly tutorial
4. Writing shell scripts using TDD and BDD principles (using shunit2) - Tutorial, Project
5. Quick Fixes for Big Headaches (the shell can be your friend) - Project
6. Deploying your own little CI Pipeline (Deploying Jenkins on your local machine) - Tutorial, Project
7. Containers for the curious (Deploying Docker on your local machine) - Tutorial, Project
8. Blending Angular, Protractor and Jasmine into a testing framework - Tutorial, Explainer, Project
9. Road Rash: Cautionary Coding tales while the wounds are still healing (I did something, I got stuck, it hurt but I figured a way out of it) - Explainer
10. How Would You Automate This (an actual Series I’m Currently Working On) - Explainer

Narrow it down to 5:

Many of the ideas I came up with are not so many ones I would want to eliminate as they are either peripheral to or prerequisite of what I'd want to write about. By taking my original list and grouping them, I came up with the following more condensed list:

1. Examining Accessibility and Inclusive Design, Walking through Developer Tools that emphasize Accessibility  - Explainer for concepts, tutorial or project for specifics
2. Making a Skeleton Resource for Coding, Writing shell scripts using TDD and BDD principles, Example shell fixes to demonstrate the project - Project
3. Deploying your own little CI Pipeline (Deploying Jenkins on your local machine), Containers for the curious (Deploying Docker on your local machine), Blending Angular, Protractor, and Jasmine into a testing framework - Tutorial, Explainer, Project
4. Road Rash: Cautionary Coding tales while the wounds are still healing (I did something, I got stuck, it hurt but I figured a way out of it) - Explainer
5. How Would You Automate This (an actual Series I’m Currently Working On) - Explainer

One of the reasons I ordered this list this way is that I couldn't figure out how to put Road Rash into another location other than as a sidebar, and it felt the weakest of my choices. How Would You Automate This I deliberately put at the bottom as I'm already writing the series. I want to emphasize posts and areas that I'm not already doing or that would actually be new territory for me.

Validate your ideas

I received some great feedback and interest from several people who reviewed my list and who expressed interest in seeing certain topics get covered. That had a lot to do with my grouping and decisions on which topics I would want to focus on.

Pick your top three

The top three and the working titles for each:

1. Making Your Pages and Apps Accessible Using Inclusive Design Principles
2. Skeleton Keys - A Project for Getting Started in bash, Python, and Ruby
3. A Testing Framework From the Ground Up - Jenkins, Docker, Angular, Protractor, Jasmine

Turn In Your Homework 

 

Turned in to the CNC2018 Facebook group, but also this blog post :).

 

Bonus Reading 

 

Here are some additional blog posts to check out:

7 Ways to Mine Twitter Data for Blog Post Ideas

Mediocre Ideas, Showing Up, and Persistence

The Code Newbie Challenge for 2018 #CNC2018: BLOG MORE: Introduction

Hello to new readers that are coming across this blog for the first time. To those who have read these pages for a while now, this should not surprise any of you at all ;).

I've decided to take on the Code Newbie Challenge for 2018. There are four "tracks" that you can choose. They are:

Start Coding
Code More
Blog More
Get a Job

I have chosen the "Blog More" challenge for a specific reason. Much of the time on this blog I have talked about testing and peripheral topics from a layman's point of view. I've strived to "speak dude" as often as possible, and to that end, I've kept coding specific stuff to a minimum. that sounds like a simple answer, doesn't it? Well, let's get real here. There's a darker secret. Part of the reason why I don't post code frequently is that I harbor a fear that people will look at my code and think it's simplistic, stupid or just plain lame. To tell the truth, that may happen. Maybe it won't. Regardless, I've always been a little leery of posting code samples beyond language tutorials because I've just been concerned about getting it picked apart.

That's the overwhelming reason why I chose this challenge. I can't get better if I don't actually put something out there, right? I can talk a mean game about what I know about things like automation and web development, but does it really matter if my actual code is lacking? More to the point, wouldn't it make a lot of sense to actually talk about code, show examples, explain it from my perspective and let people who do know about code comment on it?

Sure, it might bruise my fragile ego but isn't that the whole point? How do I expect to learn or actually demonstrate I know anything if I'm not willing to show what I actually know and take the chance that someone might be willing to tell me a better way to do it? On top of that, there may be lots of things I may be doing that are actually interesting and may be helpful to others. Finally, if I can explain what I'm doing in a blog post or several, I can explain it to anyone and draw on it when I write code in the future.

Let's get this party started. Each assignment as part of this challenge will be posted here. This is my own preamble to get the ball rolling. Look for the tags CNC2018 and CodeNewbieChallenge to see posts specifically targeted for this challenge.

Exercise Zero: The Pre Mission

Read 3 tech blog posts you wish you wrote. Jot down why you like them and what you'd change.

Find examples of good tech writing to see what you'd like to incorporate into your own posts, and what you might want to avoid. 

You'll refer back to these later in your challenge.

There are three styles that were described for this challenge. First is the "Tutorial", which actually walks through how to do something. Second is the "Explainer", which take a concept and breaks it down. Third is the "Project" which describes how to do something and gives actual examples that you can follow along and build yourself. The pre-challenge is to pick three examples, (one from each category) that I wish I had written, describe what I like about it, and what I would like to see to improve the piece.

Tutorial: "Protractor for Beginners, Part 1" by Hannah Pretswell

Why a tutorial on Protractor? Because it's what we are exploring as a replacement for our current automation framework. Nothing like a pressing business need to get your mind racing and your thoughts flowing. Hey, you know it will come in handy very soon, right? For starters, let me comment on something I really appreciate. Hannah said she struggled with getting the pieces to work together. Hearing that up front helps me in two ways. First, it lets me know that the tasks ahead may be challenging. Second, she also lets me know that she's done her best to document those frustrations and help let me know that I likely will succeed if I'm patient and follow her advice. Too often, I've gon through tutorials that expect a user to jump in and get moving with little concern over the sticking points. Gladly, that's not the case here.

Another positive is the fact that there are a fair number of repetitive steps. It's tempting to spell them all out, but by doing so, it makes updating a tutorial daunting and thus something the writer would likely not do. Instead, she points to a few additional tutorials already written that explain the process of setting up your environment and making sure everything is working correctly before getting started. Additionally, the resources listed point to the protractor GitHub page. This is a good practice because it lets the user get started with the most recent advice from the maintainer of the framework so that if the instructions change, the writer of the tutorial doesn't have to be the one to change the details on her site as well.

So, what would I have done differently? Truthfully, not much. I think it's a solid opener and it goes through the specifics as the first part of a tutorial should. I suppose I would have liked to have seen some example output of the code as displayed and some output of tests as well. For me, with a variety of tutorials, I think this is a good step so as to show what you could expect. I understand why many people don't in that OS changes and formatting details could put images like that out of date quickly, and it does add overhead to downloading what would in many cases be pictures to demonstrate the output. Still, on the whole, this is a really solid example.





Explainer: Test Driven Development in BASH by Torstein Krause Johansen

This is presented as a talk, but in many ways, that's a great way to explain a concept in a few words, with the impetus on the reader to go and learn more if they are so inclined. Specifically, I like the curt and focused content, the way the information is presented and the walkthrough of the ideas with examples. Each slide builds on the previous one and lets you see why the topic makes sense and the reasoning behind Torstein's approach. I was also excited to learn about shunit2 and I must say I'm more than a little curious at this point.

So what would I do differently? Again this is a set of slides from a talk, and at first glance, I'm guessing the HTML code was put there for a reason, but if the point was to demonstrate bash syntax and how it interacts with a testing framework, the HTML was distracting and made the underlying code hard to read. Again, I may be missing a key context here as to why that was presented that way (perhaps to prevent copying and pasting willy-nilly) but if that were the concern, I could see saving screenshots of the code itself and displaying pictures (great to prevent copy and paste but admittedly a nightmare to update and keep current).

Project: 10 Angular and TypeScript Projects to Take You From Zero to Hero by Dan Wahlin

This interested me seeing as I will be doing work with Protractor and Jasime as a testing framework for Angular apps. To that end, it helps to have something to look at, play with and practice on and these ten projects will allow me to do that. I like that the projects start simple and get progressively more difficult as they go. Each project is laid out with sample images of what you will build with links to each of the projects so that the project page is independent of each of the individual listed projects. The projects are lust listed with a title, a basic description, level of difficulty, a link to the files and some pictures of what the project will look like when completed.

On the whole, this is a nice layout and method. It leaves it up to the individual reader to decide where to expend their energy and each project simply links to the necessary packages to get them done. Were I to do it myself, I would probably split each project out to its own page and try to give some instructions about what to do with each. Having said that, the economy of having ten projects to choose from without a lot of navigation and page dancing is a good tradeoff.

There's the start. The assignments proper start on January 22, which is the same day this post goes live. Feel free to follow along and, as I tackle each assignment, your feedback and commentary is appreciated :).