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 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.

The web is inherently accessible (original)

This is the original version of this post. An updated version from 13 April 2022 is available.

I originally created Accessible Web as a sarcastic reaction to a developer changing his website to require users to disable JavaScript to use it. The reactions on Twitter were hilarious! So many angry developers didn’t get the joke that they do the same thing when they require users to have JavaScript enabled to do anything on their websites.

I decided to create something similar but with CSS. And with a message about semantic HTML. I’ve recreated the experience below.

Accessible Web - please disable CSS to view this website

Whew! That’s better. So guess what?

The web is inherently accessible

Your weekly reminder that the web is accessible by default and it’s our design decisions that stop it being accessible #a11y

k.mar (@Kevmarmol_CT) on Twitter December 7, 2020

Why did you have to disable CSS to view this website? No reason other than a design choice that excludes sighted people.

Did you know? This is how many visitors “view” webpages already:

  • Search engines
  • Bots
  • Site crawlers
  • Analytics
  • Blind people

This webpage is fully accessible to people with screen readers and Braille displays. But many websites are not due to poor design choices that exclude some people.

What is web accessibility?

When a page is accessible, it was developed with the intention of working for as many people with disabilities as possible. A good place to start learning is the W3C’s Introduction to Web Accessibility. Find out the different ways people with disabilities interact with the web.

Web Content Accessibility Guidelines (WCAG)

WCAG is a set of success criteria for determining if a page is accessible, led by four guiding principles:

  • Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
  • Operable: User interface components and navigation must be operable.
  • Understandable: Information and the operation of the user interface must be understandable.
  • Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

These contain guidelines and a hierarchy of success criteria from Level A to Level AAA. Many accessibility laws, and current best practice, point to WCAG 2.1 Level AA compliance. There are 50 discrete success criteria to evaluate, though many are not applicable to all pages. For example, if a page doesn’t contain video, you don’t have to evaluate against success criteria for captions or audio descriptions.

See the full list of success criteria

Did you know? The WCAG guidelines were first published in 1999. Web accessibility is not a new concept but a lot of people are learning about it only now.


So what’s the point? The point is to develop accessible pages from the bottom up, starting with semantic HTML. A whole lot of developers think they know HTML but are actually pretty sloppy about it. Many don’t think it matters if they use a link or a button, but it does. Every semantic mistake introduces accessibility issues into your code. If you’ve never really “learned” HTML, check out this beginner’s guide to writing good HTML.

By far, CSS color contrast issues are the most frequent accessibility issues I see, but the HTML ones are problematic too. Outlined below are the top HTML-related accessibility issues I encounter.


If you visually scan this page, you can quickly see how it is broken up into sections. That’s due to using headings or the h1-h6 elements. It’s important that every page have at least one h1 so people and search engines know what the topic of the page is. From there, cascade down to h2, h3, and so on.

Did you know? People using screen readers can navigate by headings in much the same way that sighted people can visually scan the page for items of importance.

Form labels

Every input needs a label. It’s really that simple. And best practice is to make that label visible. This helps people remember what information they’ve entered. Programmatically link each pair using the for attribute on the label matching the id attribute on the input.

This enables a couple things:

  • People can now click or tap on the label to give focus to the input. This is especially useful for checkboxes and radio buttons that often have small hit areas.
  • People using screen readers will now hear the label announced when the input is in focus.
<label for="like-cats">
<input type="checkbox" id="like-cats">Please confirm that you like cats</label>

Let people know when a field is required by adding the required attribute to inputs. Many modern browsers do cursory form field validation.

<form action="">
  <label for="cat-email">Cat's Email *</label>
  <input type="email" id="cat-email" required>

Buttons and links

Buttons and links seem very similar to some developers but they have very different semantic uses. Buttons are used for controls on a page, such as a form submit or toggle, while links are used for navigation, literally for linking to another page. If you use them interchangeably, people can get confused about what a button or link is going to do when activated.

Some people try to make their own custom buttons instead of using the <button> element, which is already accessible:

  • <button> is keyboard focusable
  • <button> is activated with enter and space keys


There are many legitimate uses for tables on the web but they are often coded incorrectly. Much as an input needs its label, a table data cell needs its table header. This allows the applicable table header to be read by a screen reader before the table data cell contents. Additionally, each table needs a <caption> that provides a description of the table contents to people using assistive technologies

About My Cats
Cat’s nameCat’s color
Stellanblack and white


The one thing about accessibility most people know is that images need alt text. This may seem straightforward but let’s look at three examples.

1) Alt text matters

Semantically speaking, every image needs an alt="" attribute. This alone will pass an automated accessibility checker. If an image is purely decorative, you can even leave the alt value empty. But if an image provides context to the content, the alt text must accurately describe the content of the image for people who cannot see it. The alt text for the image below is two cats on an easy chair under a blanket.

two cats on an easy chair under a blanket
2) SVG

SVG doesn’t support the alt attribute. Instead, add a <title> element inside the <svg> element with the alternative text description.

Add the role="img" attribute to the <svg> element to tell assistive technologies that it’s an image.

Add the aria-labelledby attribute to the <svg> element to name the image for assistive technology.

<svg role="img" aria-labelledby="svg-title">
<title id="svg-title">universal access logo</title>
transform="matrix(0.4135 0 0 0.4135 0 0)"
3) Charts and maps

Any time you display complicated information, provide a robust description of the key points of the map or chart. All people will benefit from this for reference. No matter how you mark this up— using <figcaption> or just a <p> element—give that description a unique ID.

Add the aria-describedby="unique-id" attribute to the <img> element. This programmatically connects the image with the description for assistive technologies.

Remember to include the alt attribute with a short explanation of the image. Alt text for the image below is a cat sitting on a bed that is divided up into areas.

a cat sitting on a bed that is divided up into areas
Cat bed, never used. Pillows show wake for food here and purring zone. Other areas on the bed are listed as grooming salon, sleeping area, launch pad to the bedside table, parlor, heaving spot, napping quarters, meditation area, stretching area, yoga studio, and good attack zone. A black cat sits happily in the middle of the bed.

Thanks for reading! Happy accessibility testing.


This site was inspired by Heydon’s JavaScript site

You can catch me on Twitter @racheleditullio

Source: Accessible Web About page

Grad School Statement of Intent

Hello readers! Today I came across my grad school statement of intent that I had to submit with my application to the UT iSchool in 2008. I updated it in 2012 when I added it as part of my academic portfolio.

screenshot of the home page of my academic portfolio website from grad school

In my cube at work, I have a very prominent sign with a motto by web designer Mark Wyner that reads

Visual-design integrity for people with modern devices and browsers, and information integrity for everyone else.

As a web developer, I think what lies underneath the presentation layer is the most important part of any web page. While visual design is necessary and increases usability for many users of information, it cannot and should not supersede a solid informational foundation. I am a strong proponent of Web standards, semantic markup, and accessibility for all and I believe that studying and learning at the School of Information has allowed me to better understand the ideals of data organization for which I already have a passion, ultimately making me a better web creator.

I thrive on organization, naming conventions, and process, all of which have helped me in my career as a web developer.  I have been very interested in learning about structuring data to make it optimally usable by both humans and machines, independent of the delivery method.  I want to go beyond the page level, beyond markup, and begin to classify knowledge and make it accessible to all.  I want to create information hierarchies that are easily understood so that the data can be found and used anywhere it is needed. My interests have revolved particularly around information architecture and increasing accessibility for deaf users. Whenever possible, I have chosen to pursue research assignments that have furthered my knowledge in these areas.

Until recently, I struggled to put a name to this area of study that I see as crucial for me to become the kind of professional I want to be.  When I learned that programs existed for information architecture, I felt as if I had finally found my “tribe.”  For me, specializing in information architecture is all about consolidating the wide breadth of knowledge I have around web development into a single path. I am enjoying the beginnings of my journey down that path and focusing my learning on the organization of data, usability of that data, and hope to eventually help form standards and best practices for the field. Much of my coursework has provided a solid foundation in this field and allowed me to get closer to finding my niche in user interface design and the user’s experience with information retrieval.

Through my graduate studies, I have gained an improved understanding of how users interact with information as well as the systems storing that data and the programs allowing users access to it. Another area that interests me is human factors and thus far in my career, I have had few chances to talk with users to measure their success (or frustration) with websites. Eager to learn more about the human factors aspect when designing and developing systems, I took a course on usability. It gave me a chance to design and conduct my own usability study, allowing me to observe firsthand how people approach using a website. Through these observations, I was able to make well-informed suggestions for improvement based on empirical research, not just my gut feelings about how a site should be designed.

During my career, I have made huge, personal strides towards creating more usable websites. In early 2007 I read Jeffrey Zeldman’s book Designing with Web Standards and it changed my outlook on the building of websites, opening my eyes to a new way of looking at information access. It was the first tangible explanation I had seen for structuring the data of web pages separate from the presentation layer. His work introduced me to the pure CSS coding method and taught me the concept of “semantic markup” which informs my work today. His book also led me to start studying accessibility practices and striving to make information available to all visitors, regardless of browser, device, or disability. I believe earning a Master of Science in Information Studies (MSIS)  will allow me to deepen this knowledge and understanding about what makes for good design, and that will benefit many people.

Using the tools I have acquired from studying information architecture at UT Austin, I want to move beyond being a “code-monkey,” plain and simple. I want to be at the genesis of projects, helping large organizations, such as government or academic institutions, determine the best courses of action for managing their data and creating user-friendly interfaces for retrieval of that data. I want to influence how organizations structure and maintain their information as well as influence the interface through usability testing and interviews. I want to get beyond just being the one who implements designs to being someone who helps create and define those designs with the user in mind.

I view the completion of my MSIS degree as a great beginning, one that will provided the tools and foundation that will truly create a jumping off point for me and my career. I not only learned how to organize information in more intuitive ways or how to better help users interact with information; I also gained new concepts and insights as a web professional. I know I have a lot to offer and I believe this degree will open amazing doors for me, providing the knowledge to create great designs that are usable, accessible, and have a solid base in information architecture.