Category: Accessibility

Categories
Accessibility

Accessibility is good for everyone

It’s great to see the recent changes to Automattic’s long-term hiring processes based upon a user research study into how their approach to tech hiring resonates with women and non-binary folks:

In May, Automattic’s engineering hiring team launched a user research study to better understand how our approach to tech hiring resonates with women and non-binary folks who may experience similar gender discrimination in the workplace and are experienced developers.

What changes did we make?

  • Existing work and life commitments mean that it is important to know the details of the hiring process at the outset: we have published a public page that clearly outlines our hiring process so that people have a concrete understanding of the expectations.
  • We removed all the little games from our job posting page. We were trying to test people’s attention to the job posting and filter out unmotivated candidates; it turned out we were also putting people off who we want to apply.
  • We removed all the language that emphasized that hiring is a competitive process -for instance, removing language about application volume.

Whilst I don’t fit into their target audience for this study, if these changes had been implemented earlier I would have personally benefited from these, instead of being disheartened about waiting for 4 years for a response to a job application that never came (I did eventually work up the courage to apply again at which time I was successful).

This example shows that making your recruitment processes more clear and accessible makes it better for everyone, not just those who experience discrimination – much like web accessibility benefits everyone, regardless of ability.

Categories
Accessibility Conferences

Notes from the 2015 ANZTB Conference in Auckland

I was lucky enough to make my first trans-Tasman journey to Auckland last week to attend the 2015 ANZTB Conference. The conference was enjoyable and there were some memorable talks I really enjoyed (I personally like single-stream events). Here’s some favorites:

Secure by Design – Laura Bell – slides

I loved the essence of this talk which was basically (in my own words) ‘take security testing off the pedestal’. Laura shared five simple tools and techniques to make security more accessible for developers and testers alike. One key takeaway for me was to focus on getting the language right: ‘security vulnerabilities hide behind acronyms, jargon and assumptions‘. For example, most people understand the different between authentication (providing identity) and authorization (access rights), but both these terms are commonly shortened to ‘auth’ which most people use interchangeably (and confusingly). A great talk.

Innovation through Collaboration – Wil McLellan

This was probably my favorite talk of the day, as it was a well told story about building a collaborative co-working space called ‘EPIC’ for IT start-ups in Christchurch following the 2011 earth quake. The theme was how collaboration encourages innovation, and even companies in competition benefit through collaboration. My key takeaway was how designing a space you can encourage collaboration, for example, in EPIC there’s only a single kitchen for the whole building, and each tenancy doesn’t has it’s own water. So, if someone wants a drink or something to eat they need to visit a communal area. Doing this enough times means you start interacting with others in the building you wouldn’t normally do so in your day to day work.

Through a different lens – Sarah Pulis – slides

Sarah is the Head of Accessibility Services at PwC in Sydney and she shared some good background information about why accessibility is important and some of the key resources to analyse/evaluate and improve accessibility of systems. Whilst I knew most of the resources she mentioned, I thought here talk was very well put together.

Well done to the team that organized the conference.

Auckland was a beautiful city BTW, here’s a couple of pics I took:

Categories
Accessibility

Tips for testing iOS app accessibility using VoiceOver

I really enjoy testing iOS app accessibility using VoiceOver but for newbies it can be a little tricky to get started. Here’s some testing tips:

Use VoiceOver on a real iOS device to test accessibility

You can’t use VoiceOver on the iOS simulator, which is a good thing because it relies so much upon input gestures which can be mastered using a physical device, so you’ll need to test your app on a real iOS device. If you are creating an iPhone application and don’t have access to an iPhone, you can use a cheaper iPod touch for VoiceOver accessibility testing.

Use triple click home button to enable/disable VoiceOver

The first time you use VoiceOver is quite confusing as it basically entirely changes the way the operating system behaves. You can set an Accessibility Shortcut in the Accessibility menu of iOS so that triple click home toggles VoiceOver on/off. This is good for when you get stuck and you don’t need to navigate the menus with VoiceOver on to turn it off.

Triple Click Home VoiceOver iOS7

Master the gestures

VoiceOver has completely different gestures than standard gestures so you’ll want to practice them. The most common gesture is swipe/left right to select different elements which then require a double tap to activate (a standard tap). Two finger swipe up reads all elements from top of the screen and two finger swipe down reads from the bottom of the screen. There’s a useful guide to VoiceOver gestures available on the iOS developer site.

Use Screen Curtain

If you want to test your app is truly accessible then you can close your eyes, but if you are like me and might peek, use Screen Curtain (three finger triple tap) which blanks the screen entirely but leaves VoiceOver running so you using your app without a visual display. Neat.

Summary

The best way to do iOS accessibility is to dive in and get started. If you’re like me you’ll pick it up quickly and find it fun to do.

Categories
Accessibility

Tips for making your iOS app accessible

I’ve been doing some work recently on native iOS app accessibility and have started to see common issues appearing related to accessibility that can be resolved by using a common approach.

It’s important to note that accessibility is enabled by default on all iOS app development and if you don’t do anything crazy then your app should be mostly accessible, but it is still worth checking and keeping an eye out for common mistakes.

I do all my testing on a device using VoiceOver but I won’t detail that here, instead, I will write a separate blog post with some tips on VoiceOver testing.

Here’s some tips on making your iOS app accessible:

Enable form field tabbing

A VoiceOver user moves between elements using gestures, so on a form you should make it easy for a VoiceOver user to move between the fields by making a ‘return’ action on each field that moves to the next field, or submits the form on the last field. Apple goes above and beyond this functionality in its own native apps by putting accessible “Previous”, “Next”, and “Done” elements above the keyboard on forms which are recognized by VoiceOver and make it super easy to navigate and submit a form.

Apple Form Accessibility Example

Make embedded UIWebViews accessible

If you embed any HTML content in your native app then you should mark the UIWebView as an accessible element, but very importantly, don’t mark its parent as accessible, otherwise the UIWebView won’t be accessible via VoiceOver. Once you’ve done this, VoiceOver reads the content in the same way it does a web page in Safari.

Make UIPageControl page indicators accessible

When you have multiple horizontal pages in a UIPageControl, the page indicators are the dots that appear at the bottom of the control that indicate which page you are on as you swipe left/right through the pages. VoiceOver uses the swipe left/right gestures for navigation so a VoiceOver user won’t be able to switch between your pages unless they use the page indicators.

page indicators ios

Page indicators aren’t automatically accessible, you must do two things. First set the accessibility trait to UIAccessibilityTraitAdjustable and then implement a accessibilityIncrement and accessibilityDecrement which changes the pages. This means a VoiceOver user can focus on the element and use slider up/down from the top of the screen to navigate pages.

Ensure appropriate color contrast

This isn’t specific to VoiceOver testing but ensuring your application is accessible to visually impaired or color blind users. An example I have seen recently is a black ‘copy/paste’ popup on a black form.

black on black

Summary

Making accessible iOS isn’t difficult because Apple has done a lot of work to ensure accessibility is built into the development platform. The key is to build these features in as you go and continually test on a device using VoiceOver enabled.

More Information

There’s some great information here and here about iOS accessibility from Apple.

Categories
Accessibility Automated Acceptance Testing

Accessible Pizza

I gave a ten minute presentation at the ANZTB Test 2013 conference in Canberra this afternoon on Accessible Pizza: Automated Accessibility Testing for Pizza Eaters.

Click the slide below to see the slideshow.

Accessible Pizza

Bonus

I saw a black swan on my walk at lunch

Canberra Black Swan

Categories
Accessibility Automated Testing

Automated local accessibility testing using WAVE and WebDriver

I wrote a while back about automated WCAG 2.0 accessibility testing in our build pipeline.

My solution involved capturing the HTML of each unique page in our application visited via WebDriver, then navigating to the online WAVE tool to check the accessibility of each chunk of HTML, all done during a dedicated accessibility stage of our build pipeline.

That was working pretty well until I noticed our IP address was starting to become blocked by WAVE due to a unreasonable number of checks… Doh!

Locally we’ve all been using the Firefox WAVE toolbar, as it’s very easy to run against a locally running instance of our application. Which made me think: how do I automate the Firefox WAVE toolbar to avoid having to use the WAVE web site alltogether?

Today I changed our accessibility tests to use the WAVE toolbar. It was a bit of a pain since we use Windows and the WAVE toolbar seems to be broken in configuring Firefox shortcut keys to trigger accessibility checks.

What I ended up doing is firing the keystrokes needed to run the check via the Tools menu in Firefox. I then check the DOM to ensure there are no WAVE errors and screenshot it and fail the test if there are. Quite simple really, and it works very reliably and quickly.

Makes me think I should have done this to start with, but a good outcome nonetheless.

Some C# WebDriver code to do this follows. This should be easy to adapt to another language.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using OpenQA.Selenium;
using OpenQA.Selenium.Firefox;
using System.Drawing.Imaging;

namespace Dominos.OLO.Html5.Tests.Acceptance
{
    [TestClass]
    public class AccessibilityTests
    {
        [TestMethod]
        public void AccessibilityTest()
        {
            var profile = new FirefoxProfile();
            profile.AddExtension("wavetoolbar1_1_8_en.xpi");
            var driver = new FirefoxDriver(profile);

            driver.Navigate().GoToUrl("http://apple.com");

            var b = driver.FindElement(By.TagName("body"));
            b.SendKeys(Keys.Alt + "T");
            b.SendKeys(Keys.ArrowDown);
            b.SendKeys(Keys.ArrowDown);
            b.SendKeys(Keys.ArrowDown);
            b.SendKeys(Keys.ArrowDown);
            b.SendKeys(Keys.ArrowRight);
            b.SendKeys(Keys.Enter);

            var waveTips = driver.FindElements(By.ClassName("wave4tip"));
            if (waveTips.Count == 0) Assert.Fail("Could not locate any WAVE validations - please ensure that WAVE is installed correctly");
            foreach (var waveTip in waveTips)
            {
                if (!waveTip.GetAttribute("alt").StartsWith("ERROR:")) continue;
                var fileName = String.Format("{0}{1}{2}", "WAVE", DateTime.Now.ToString("HHmmss"), ".png");
                var screenShot = ((ITakesScreenshot)driver).GetScreenshot();
                screenShot.SaveAsFile(fileName, ImageFormat.Png);
                Assert.Fail("WAVE errors were found on the page. Please see screenshot for details");
            }
        }
    }
}

and finally the resulting screenshot:

Apple WAVE check results

Categories
Accessibility Automated Testing Continuous Delivery Continuous Integration Test Automation

Automated WCAG 2.0 accessibility testing in the build pipeline

The web application I am currently working on must meet accessibility standards: WCAG 2.0 AA to be precise. WCAG 2.0 is a collection of guidelines that ensure your site is accessible for people with disabilities.

An example of poor accessibility design is missing an alt tag on an image, or not specifying a language of a document, eg:

<HTML lang="fr">

Building Accessibility In

Whilst later we’ll do doing accessibility assessments with people who are blind or have low vision, we need to make sure we build accessibility in. To do this, we need automated accessibility tests as part of our continuous integration build pipeline. My challenge this week was to do just this.

Automated Accessibility Tests

First I needed to find a tool to validate against the spec. We’re developing the web application locally so we’ll need to run it locally. There’s a tool called TotalValidator which offers a command line tool, the only downside is the licensing cost, as to use the command line version you need to buy at least 6 copies of the tool at £25 per copy, approximately US$240 in total. There’s no trial of command line tool unless you buy at least one copy of the pro tool at £25. I didn’t want to spend money on something that might not work so I kept looking for alternatives.

There are two sites I found that validate accessibility by URL or supplied HTML code: AChecker and WAVE.

AChecker: this tool which works really well. It even supplies an REST API, but I couldn’t find a way to call the API to validate HTML code (instead of by URL) which is what I would like to do. The software behind AChecker is open source (PHP) so you can actually install your own version behind your firewall if you wish.

WAVE: a new tool recently released by WebAim: Web Accessibility in Mind. Again this is an online checker that allows you to validate by URL or HTML code supplied, but unfortunately there’s no API (yet) and the results aren’t as easy to programatically read.

My Solution

The final solution I came up with is a specific tagged web accessibility feature in our acceptance tests project. This has scenarios that use WebDriver to navigate through our application capturing the HTML source code from each page visited. Finally, it visits the AChecker tool online and validates each piece of HTML source code it collected and fails the build if any accessibility problems are found.

AChecker Results

Build Light

We have a specific build light that runs all the automated acceptance tests and accessibility tests. If any of these fail, the light goes red.

Build Status Lights

It’s much better if it looks like this:

Build Lights All Green

Summary

It was fairly easy to use an existing free online accessibility checker to validate all HTML code in your local application, and make this status highly visible to the development team. By building accessibility in, we’re reducing the expected number of issues when we conduct more formal accessibility testing.

Bonus Points: faster accessibility feedback

Ideally, as a page is being developed, the developer/tester should be able to check accessibility (rather than waiting for the build to fail). The easiest way I have found behind a firewall is to use the WAVE Firefox extension, which displays errors as you use your site. Fantastic!

(Apple and Microsoft each have one known accessibility problem, Google has nine!)

Apple.com accessibility