Showing posts with label BlogMore. Show all posts
Showing posts with label BlogMore. Show all posts

Monday, March 5, 2018

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.

Monday, February 5, 2018

The Code Newbie Challenge for 2018 #CNC2018: BLOG MORE: Mission Two: Blog Outlines and Schedules



Week three and mission two are completed. My thanks to Christian Haas for feedback and some additional commentary in this post :).


This week's homework for Blog More is to complete an outline for each of the three blog post ideas.


Homework:
1. Post your favorite outline below.
2. Find someone’s posted outline in the group and give them some feedback. What stands out to you? What points were most interesting? What did you want to learn more about? Be kind but specific in your feedback.

Mission 2:  Outlines and Schedules

My Top Three

1. Writing Code around Accessibility and Inclusive Design
  • Intro: a quick explanation as to what Accessibility and Inclusive Design are.
  • Sample Code that is not accessible and why (web example)
  • Using Inclusive Design Patterns to help set the stage
  • Changes to code that will make it more accessible
  • Methods to check and validate such things
  • Sample Code that now IS accessible and why (web example)


My initial thoughts: 
I’m realizing this is a topic I could write examples for every week for a year and probably still have plenty to write about. I will probably have to tailor this down to an introductory article first and then go into specifics about individual inclusive design patterns, etc.

Christian's comments:
I'm curious about this topic as a whole. For me, your first entry could be about setting the stage, with one or two examples showcasing how far the topic could reach. I myself am more interested from a theoretical point of view. It would affect my daily work only if there were info/references to "closed" systems; I'm not working on web UI, but for a dedicated, trained, target audience using Java UI.

My follow-on thoughts based on feedback:
This is an interesting angle and one I hadn't considered. How do we make applications accessible in a more specific programmatic focus? By Java UI I am assuming these are applications that have a command line style interface or otherwise interactions at the Operating System level and not online or via the web. To be honest, I haven't given a lot of thought to how this would work for a command line application, but it's an interesting thought experiment. When I'm writing a script or some interactive piece of code, how Accessible or Inclusive am I making those interactions? Definitely worth considering.

2. Skeleton Keys: a resource for TDD/BDD in the shell and other programming languages
  • What is skeleton-keys?
  • Why would anyone need it?
  • TDD/BDD in the shell? Really?
  • Unit Testing Tools in three languages (bash, ruby, and python)
  • Starting small: structure, tests, and output
  • Compare and Contrast the three languages and approaches

My initial thoughts:
Why did I pick three languages? OY!!! Oh yeah, so I could actually make some comparisons. I think these might end up being rather long (like book chapter long), but on the plus side, once I get this started, I will probably have plenty to write about for a very long time.

Christina's comments:
Bash: yes - Ruby/Python: is there a particular reason to have both? I don't have experience in either language and see (from the outside) they are somewhat similar in terms of capabilities. Mainly procedural with object-oriented additions; weak type system, and interpreted. For a broader coverage, it should have a variation in perhaps at least two of these points. (e.g., using C, C++, Java, C#, Go, or ...). Since you already identify that this can be done in various languages (taking time and effort to write this), I suggest that, if you want three initial examples, they should be quite distinct from each other. Or reduce to two. (Or give particular reason why Ruby & Python)

My follow-on thoughts:
This is a very good point. I picked Ruby and Python mostly because they are languages I'd been either working with or had some recent exposure to and wanted to set up as a way to focus on some starting poitns for those languages. Having said that, they are two languages that fill a similar niche. They're not the exact same, but Christian makes a good point that they are similar enough that they may not prove to be all that interesting a comparison. Perhaps using a language such as Java or C++ would make more sense, though I haven't used either in a meaningful way in a long time. Still, for this purpose, it may make for a more interesting comparison, so worth re-examining.


3. Creating a framework from the ground up (Jenkins, Docker, Protractor, Angular, Jasmine)
  • You Keep using that ‘Framework’ word. I don’t think it means what you think it means.
  • Jigging your Jig-Saw Pieces (short intro/tutorial on all five pieces, including installation)
  • Setting up a basic application to test
  • Puting the onion back together
  • writing the Angular App
  • testing with Protractor/Jasmine
  • putting it into Docker
  • managing it with Jenkins
  • Lather, rinse, repeat


My initial thoughts: 
This would make for a great series with a minimum of five posts for each piece (plus the many that I haven’t even mentioned yet, such as plug-ins or add ons to make the job easier to manage).

Christian's comments:
With your first point about using "framework" wrong, I suspect this title is intentional. Still, is the overall goal to write a Javascript based template project?
If so, I'd be less interested as I don't work in JavaScript (That should not be a reason to change your goal, I understand that), though, if it were pitched as "how to create a template stack with Jenkins, Docker, ..." might be half interested as I'd consider an automation pipeline for different languages. Perhaps this could even be a two-parter: How to set up a build-pipeline with Jenkins & Docker and then specializing it for a JavaScript project, and then specializing it for a Java project for instance... (These are all just ideas, I believe your thoughts go already in that direction...)

My follow-on thoughts:
Yes, the use of the word "framework" in both the title and the shout-out to The Princess Bride reference is in part to say that the word framework gets thrown around a lot and maybe doesn't really mean what a lot of people think it means. My goal is to address the broad areas and try to see how to implement the pieces. Just setting up the scenario would be a series of posts (setting up Jenkins, working with git, creating docker containers, setting up a project, making tests for the project, running those tests, making sure they integrate with the CI pipeline, etc.). Perhaps skeleton-keys could be the project that allows me to put this all together and integrate into a series of posts.


One thing is certain, this challenge series is showing me that there are plenty of things to write about in these spaces and I will probably have ample to write about for a long time.

Monday, January 29, 2018

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: