Global Accessibility Awareness Day 2021

The third Thursday in May is Global Accessibility Awareness Day (GAAD).

The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than one billion people with disabilities/impairments.

GAAD homepage

Spring is all around here in Texas, with loads of beautiful blooms like these poppies—a flower often associated with war casualties in the West. It seems like a poignant symbol right now as we assess the loss of lives and survivor health issues of those affected by COVID-19, including millions of people with disabilities.

Beyond trying to avoid physical sickness, disabled people have faced enormous challenges in getting tested, treated and vaccinated. The US healthcare system and government social safety net programs are enormously difficult to navigate with numerous barriers for people trying to get information digitally. A few examples:

  • Coronavirus maps and data in unstructured formats
  • COVID-19 websites that don’t work with screen readers
  • Drive-through only testing and vaccination sites
  • Critical information missing text equivalents, like video captions
  • Vaccine-finder websites with poor mobile support

I spend dozens of hours every week evaluating digital experiences as an accessibility engineer. It’s my job to find weaknesses in the ways information is presented to people. Most of the time, I’m documenting code issues that by themselves are small barriers but combined across a website cause enough inaccessibility that people can’t do what they want to do. I wonder how many disabled people already struggling in a culture that sees us as lesser couldn’t get a test or can’t schedule a vaccination because the people who built these websites didn’t even consider our needs.

I think about my needs as an autistic person with ADHD and bipolar disorder. I’m easily distracted and easily nauseated by moving content. The media query prefers-reduced-motion was made for me. I want to rid the web of every auto-advancing carousel I see. But despite a lot of evidence carousels are ineffective, they are still ubiquitous.

Every day sees more research about why digital accessibility is necessary, and it comes with endless anecdotes from people using assistive technology about how the web and mobile landscapes are still wildly unusable. This problem has been framed as an empathy problem, a coding knowledge problem, even as just a cost problem. So, how do we get designers and developers to care about the needs of the disabled?

It’s clear that accessibility as a concept is not considered a core tenet of good design and development by the establishment. Focus remains largely on the normative desktop browser experience that centers sighted, hearing users without cognitive or mobility impairments. It’s hard to imagine that there is much more we can do in this fight for visibility and inclusion.

I hope this GAAD, you believe you have a right to access information and will demand that right be honored. The time has passed where anyone creating for the web can plausibly deny knowing about accessibility. Whether it’s pointing out missing captions and alt text on social media or contacting customer service about issues a site has supporting assistive technology, each of our small voices can combine into a collective clamor for inclusive design.

My Accessibility Journey

This post follows my path to discovering a passion for accessibility and landing my dream job as an accessibility engineer.

Starting out on rocky flats (2000-2007)

It took me several years to become a decent web developer. Self-taught, I learned HTML through view source on webpages; I used code snippets from online tutorials; I built nested tables for layout. As the browser wars raged, most people didn’t care if the code was good so long as the website looked pixel perfect.

a screenshot of a dated website with the graphical heading bienvenue, three columns with left navigation, text in the middle, and a right rail with a link to email address.
My personal website circa 2000

During university, my plan was to be a high school English teacher. My last semester, I realized I enjoyed coding more and would make a better wage building websites. Two months after graduating, I started my first full-time tech job. I got hired because I was the only candidate with any web experience. Acting as designer, developer and content author, I built the first website for a small manufacturing company in late 2000 as the dot com bubble burst.

screenshot of the Texas EIFS homepage circa 2000. There are several images without alt text.
Texas EIFS first website circa 2000

After a couple of months, life took me to California where I got my second web developer role, this time for a manufacturing software company. I distinctly remember coming in to interview and having to do a coding test to prove I knew HTML. In this job, I learned how to work on multiple projects and maintain several different websites. I helped them with their first website redesign, as well as create a separate website for user conferences.

screenshot of the QAD software website hoe page with a left rail and top tabbed navigation.
QAD homepage circa 2002

I spent most days fielding requests to update website content. Towards the end of my six years at QAD, I learned about portal and content management systems (CMS) as we went through a second redesign. This helped me get my next web developer job, which was at the CMS company, back in Texas.

Hiking through the forest (2007-2012)

It was 2007 and I needed to know CSS for the task of redesigning a website from a table-based layout and static HTML into a CSS-based layout with content in a CMS. I picked up a book that changed my life.

book cover for designing with web standards. it shows the top half of the author's head wearing his iconic blue beanie hat.

Designing with Web Standards

Jeffrey Zeldman

For a self-learner like me, Zeldman’s seminal book helped several pieces fall into place. I learned web standards were a thing and there were actual guidelines for creating semantic webpages. I learned CSS and how to keep design separate from content. I started reading two newsletters: A List Apart and Sitepoint. My world just opened up when I found all these people writing about the web standards way of doing things. I had my first introduction to accessibility in this 2007 article, JavaScript and Screen Readers.

screenshot of the vignette.com homepage circa 2009. it has top navigation, a hero banner, then a three column content area below.
Vignette website circa 2009

I learned from a co-worker that the University of Texas at Austin had a program with an “information architecture” (IA) track and in 2009 I started graduate work on a Master of Science in Information Studies degree (a.k.a. library school). The curriculum wasn’t as robust as I hoped, but it gave me a flexible framework to explore my interests around usability and accessibility. After 3.5 years of working full-time and going to school part-time, I graduated in 2012 with an endorsement of specialization in user experience design (UXD). This included two courses on making systems work for people with disabilities.

screenshot of my academic portfolio home page.
Academic Portfolio circa 2012

It was around this time that mobile browsing and responsive design were getting real attention from the development world, along with HTML5 and CSS3. I incorporated these technologies in my projects but my career desires were shifting left from developing to designing. I wanted to do user experience design work.

Switchback up the north face (2012-2020)

I tried for years to improve our user experience process at work. I advocated for creating prototypes and using those for low-fidelity usability testing of all our application changes. There was interest but no commitment. While I was able create more functional design documentation over time, we had only one project that included personas, wireframes and testing with end users.

wireframe of the agenda builder project.
Agenda Builder circa 2014

In 2015, I shifted my focus again, this time to accessibility. I performed the first accessibility audit of OpenText’s corporate website using the W3C’s Web Accessibility Initiative Easy Checks – A First Review of Web Accessibility. In retrospect, this was a transformative act because it started the accessibility conversation with Marketing and IT at OpenText. I also started my blog which let me explore usability and accessibility issues in the wild, improving my auditing skills.

I learned as much about accessibility as I could through webinars, online courses, Twitter and conferences. I’m very lucky to live in Austin where the AccessU accessibility conference is held each spring. In 2018, I learned about the International Association of Accessibility Professionals (IAAP) and certifications available. In 2019, I passed the exam for the Web Accessibility Specialist credential after years of checking websites and fixing accessibility issues.

IAAP WAS certificate for Rachele DiTullio awarded March 19, 2019.
Web Accessibility Specialist certification

Integrating accessibility at work was slow going with many struggles. In 2020, I started looking for a job with an accessibility-focus, somewhere that accessibility is valued and non-negotiable. Just after I took the next IAAP exam, Certified Professional in Accessibility Core Competencies, COVID-19 interrupted everything. I decided to halt my job search until 2021 to see whether OpenText would come into compliance with the Accessibility for Ontarians with Disabilities Act (AODA) by 1 January.

Reaching the summit

The new year came without any firm support for an accessibility program in IT, however Marketing pledged not to publish any new content that does not conform to WCAG 2.0 level AA, which I consider a huge win.

On the side, I picked up an accessibility contracting job and had my first exposure to a robust accessibility testing methodology. Another piece fell into place and I learned so much in six weeks about the process of testing as well as how to test native mobile applications. Soon after, I started interviewing for an accessibility engineer position at another accessibility firm.

I wanted a remote-only position after all this time working from home during the pandemic. I wanted a raise. I wanted to find meaningful work. And I got the job! I’m very excited to start this next chapter of my accessibility journey.

In my exit interview, I let my former employer know that I didn’t feel right working on websites that excluded disabled people. It felt good taking a stand and finding work that will improve information access for everyone.

Improving numerical data entry on mobile devices

When I order something online, usually from my phone, I have to enter different pieces of numerical information. If you use a mobile device, you’ve probably noticed that depending on what kind of information a form field requests, you’re sometimes presented with different on-screen keyboards.

Here is a side-by-side example for entering a credit card number:

a credit card number form input showing a numerical keyboard when the field is in focus
Numbers keyboard
a credit card number field on a form showing the regular A-Z keyboard on screen
Standard keyboard

Which of these keyboards makes it easier to enter a credit card number? For most people, it’s going to be the numbers keyboard.

  • Reduces time on task: There’s no need to switch to the numerical view of the standard keyboard when the UI provides access to the numbers keyboard.

  • Lessens cognitive load: You’re presented with a telephone keypad which centers numerical inputs over letters or symbols.

  • Increases accuracy: The number keys are over three times the size of the standard keyboard which reduces entry errors.

Use the proper input type

Enabling the numbers keyboard for certain input types is a great usability improvement. But what about accessibility? We need to ensure we’re programmatically indicating what kind of numerical data the input requires and that we’re displaying the right version of the numbers keyboard as there are slight variations.

The HTML specification includes 21 input type attributes. One of the types is actually number but its intended use is for setting a value in a range rather than for just anything that might be numeric:

The input element represents a control for setting the element’s value to a string representing a number.

4.10.5.1.12 Number state
<label>How much do you want to charge? $<input type="number" min="0" step="0.01" name="price"></label>

We also need to keep in mind success criteria 1.3.5: Identify Input Purpose which requires setting autocomplete attributes to ease data entry. Let’s look at how to properly mark-up inputs for telephone number, zip code and credit card number.

Telephone number

Use input type="tel" to enable the numbers keyboard. With the autocomplete="tel" attribute included, we can see how iOS offers telephone number suggestions as well.

<input autocomplete="tel" name="phone_number" id="phone_number" type="tel" value="">
telephone form field on Twitter which displays the numerical telephone keyboard on focus
Telephone input

Zip code

Since all postal codes are not numbers-only like US zip codes, use input type="text" and set the pattern attribute to enable the numbers keyboard. Include autocomplete="postal-code".

This example is for US zip code entry of 5 digits, 0-9.

<input type="text" id="deliveryZipInput" value="" maxlength="5" autocomplete="postal-code" pattern="^([0-9]{5})$">
a zip code input displays the numbers keyboard
Zip code input

Credit card number

Again, use input type="text" and include the pattern attribute for a 16-digit number. If you want to validate against different credit card types, use the appropriate regular expressions in your pattern attributes such as this one for Visa: ^4[0-9]{12}(?:[0-9]{3})?$

<input type="text" id="x_card_num" maxlength="16" name="x_card_num" pattern="[0-9]*" value="" autocomplete="cc-number">
screen shot of a payment screen with credit card number field in focus and numbers keyboard displayed on screen
Credit card number input

Other types

Other numerical types you might want to experiment with include date, month, time and range. Just don’t default to input type="tel" when the goal is to display the numbers keyboard.