accessibility Archives - Page 10 of 13

Course: Developing with Empathy

Rachele DiTullio2 April 20181 February 2021Desktopaccessibility

Today I finished another free web accessibility course. This one is from Google and hosted by Udacity: Developing with Empathy

I find it hard to explain to other developers about having empathy for all web users, not just those who resemble ourselves. Courses like this are a great place to point those who might not be convinced that accessibility is important, especially those of us who work on projects that have little to no legal accessibility requirements.

This course is designed around four concepts:

Providing and managing focus of elements for keyboard and switch users
Constructing pages with good semantics and understanding the accessibility tree in the DOM
A basic look at ARIA features
Putting these together with style

I enjoyed learning about ChromeVox which emulates using a screen reader. The controls take some learning but it’s a useful way to test some of the hidden features of accessibility like aria-required on a form field.

Another helpful accessibility tool from this course is the Accessibility Developer Tools available through Chrome. It lets you perform an accessibility audit on a page and provides tips for improvements.

Here’s an audit of this blog’s front page.

screen shot of the results from an accessibility audit of the Fishy UX front page showing a score of 95 — *Fishy UX accessibility audit*

AccessNow app

Rachele DiTullio20 March 201811 February 2021In Real Life, Mobileaccessibility

A new app out of Canada, AccessNow, aims to crowdsource the accessibility of communities. Maayan Ziv, a wheelchair user, has made it her life’s work to help others know which places are accessible before going out.

As she told CBC News in Access Now uses crowdsourcing to pinpoint accessible businesses

“Recently, I went to a place and there were three steps at the entrance, and I was told it was accessible. I get to the entrance, and there are those steps and then I’m stuck in the middle of the street without any options.”

I downloaded this app for iPhone to check out what’s going on in Austin. The app doesn’t have many places reviewed here just yet, with only four entries showing up for the Central Austin/UT Campus/Downtown area.

AccessNow map viewIn addition to a searchable map display, the app also has a list view. Icons from a green thumbs up for accessible to a red thumbs down for inaccessible help users know what to expect when experiencing a mobility impairment.

screenshot showing 4 map pins — AccessNow map view

Users can outline specific issues in a description.

screen shot explaining the accessibility issues with the Austin Panic Room — *AccessNow app place details*

Per the Americans with Disabilities Act of 1990, new construction and any existing construction that undergoes major renovations are supposed to be accessible. I see how this app would be especially useful for rating those places that were built before the act went into effect.

Users who have created an account can add new entries by tapping the ‘add pin’ icon, searching for a place, then entering details. The app provides several tags like accessible parking, automatic door and ramp, as well as an area to type out a description.

screen shot of the add place screen with options to rate how accessible it is — AccessNow add new place screen

Learn more from this interview with the creator.

Texas Gas Service Homepage

Rachele DiTullio7 November 2017Websiteaccessibility, forms

Another accessibility disaster. It’s great that people are finding creative ways to use JavaScript but it is not okay to ignore progressive enhancement techniques.

Your users should never see this instead of content:

Our site requires javascript, please enable javascript and refresh the browser window.

JS frameworks do a disservice to the Web after all the innovation and hard work that has gone into creating a separation model for content, presentation and client-side scripting.

drawing of a peanut M&M candy showing content as the peanut, presentation as the chocolate layer and client-side scripting as the candy shell — *Layering content, presentation and client-side scripting – Drawing by Dave Stewart*

The Texas Gas Service website gives us lots of examples. Let’s see how well we can use the site without a mouse, a.k.a tabbing through.

(Step 0: What is with this trend to play videos as background images? I thought we learned this lesson years ago. Having movement your users can’t disable is annoying and bad practice. Stop it.)

screenshot of the Texas Gas Service home page with user login form — *Texas Gas Service homepage*

Links I can’t click; let me count the ways
From the “I want to…” select menu to the hamburger menu to the footer, dozens of “links” are not marked up as <a href> and cannot be tabbed to, nor would they be read as links by a screen reader.

These aren’t links

This is lazy and wrong. If something is a link, make it a link. Fake links achieved with JS only are a large accessibility barrier.

<div click.delegate="goTo('home', true)" class="btn pill-btn white-fill-btn au-target" show.bind="!session.loggedIn" au-target-id="111">Pay my bill</div>
Tabbing order fail
The tabindex attribute can be a really useful tool. It can also completely screw up a user’s ability to access important information, like the “username” field. When I could not tab to the “username” field, I looked at the code and saw the field was set to tabindex=-1. I had to look this one up. Here’s a 2014 explanation from The Paciello Group:

When tabindex is set to a negative integer like -1, it becomes programmatically focusable but it isn’t included in the tab order. In other words, it can’t be reached by someone using the tab key to navigate through content, but it can be focused on with scripting.

From my perspective as a customer who visits this page, being able to log in is the number one user story but it isn’t possible using a keyboard.
Form validation errors
The only time the “username” field seems to get focus is if that field is empty when clicking the “Login” button. Plenty of client-side field validation solutions work without removing a field from the tabbing order.

Login form validation errors with login button disabled

If a user tries to login with bad data, a small modal window with a an unhelpful developer-style error message of “Login failed” appears at the top right of the page. There is no associated help text about the causes of the error, or which fields have errors, and focus is removed from the form making it that much harder to update the data.

Login failed error modal window

Adding to the confusion is the little green check in both fields indicating what would usually mean the field data is valid. But for this form, a green check merely indicates that a field isn’t blank. There isn’t any robust client-side validation occurring at all.

Pet peeve: What is the point of removing the browser scrollbar from the page? It provides a simple and useful way to indicate where I am on the page. This is something I really miss on mobile devices.