+48 690 748 544
Language:

Article

The History of Digital Accessibility: When Not Everyone Could Use the Digital World

Explore the history of digital accessibility, from the IBM Screen Reader and early Web to WCAG, WAI-ARIA, EN 301 549, and the European Accessibility Act.

September 22, 202611 min read
  • Digital accessibility
  • WCAG
  • Web history
  • Accessibility history
  • Humor

The internet is a little like electricity. When it works, we rarely stop to think about it. We transfer money, order food, buy tickets, sign contracts, book medical appointments, and unsubscribe from newsletters—although that last one can still be an adventure 🙂

It was not always this way, especially not for everyone.

For much of computing history, interfaces quietly assumed that every user could see, hear, use a mouse, hit a 12-pixel target, distinguish colors, read small text, and somehow know that gray text on a gray background was a link.

If you did not meet those requirements? Well, perhaps you could play Minesweeper. That is a joke, of course. Minesweeper was hardly a model of accessibility either 🙂

The history of digital accessibility is the story of software and the Web gradually learning that the user is not necessarily the problem. The interface may be the problem.

Before the Web learned to speak: the IBM Screen Reader

Digital accessibility began before the Web. Computers became increasingly useful during the 1980s, but information shown on a screen generally had to be seen. A fairly important detail if you happened to be blind.

At IBM, blind programmer Jim Thatcher was among the people working on that problem. The IBM Screen Reader arrived in 1984 as a pioneering system that enabled blind people to use a computer through synthesized speech.

The computer could do more than display information. It could say it aloud.

That breakthrough revealed a problem we still know today: a screen reader can communicate only what an interface exposes in a meaningful way. If a developer creates a clickable div with no correct semantics, assistive technology does not suddenly acquire telepathy.

ARIA is not telepathy either, although some modern components appear to expect it to be.

1990: the user is not always the problem

The Americans with Disabilities Act (ADA) was signed into US law on 26 July 1990. It was not written specifically for websites—the Web had barely begun—but it reflected a broader shift in the understanding of disability.

If a wheelchair user cannot enter a building, you could say, “They cannot enter because they use a wheelchair.” You could describe the same situation differently: “They cannot enter because we designed an entrance with stairs and no alternative.”

The distinction seems small. It changes everything.

The same way of thinking later reached digital products. If someone cannot complete a form with a keyboard, perhaps the user is not the problem. Perhaps the form is. Plot twist: very often, it is the form.

1991: the World Wide Web and accessibility through simplicity

The first HTTP server and website were already running by the end of 1990. In 1991, Tim Berners-Lee began sharing the Web more widely—first with the high-energy physics community and later with the hypertext and NeXT communities. He recounts this in his short personal history of the World Wide Web. The early Web was mostly text, links, and connected documents.

There were no autoplay videos, newsletter pop-ups, or cookie banners where “Accept all” fills half the screen while “Reject” hides somewhere between the privacy policy and Narnia.

In many respects, the early Web was fairly accessible. HTML carried meaning through headings, paragraphs, lists, and links. Then we discovered that websites could look spectacular.

The 1990s: “Best viewed in…” and the rise of barriers

Anyone who remembers the 1990s Web may recall badges reading “Best viewed in Internet Explorer” or “Best viewed at 800×600.” It was an elegant way of telling visitors, “The website works; you simply brought the wrong tools.”

Designers experimented with layout tables, images containing text, animated GIFs, Flash, and JavaScript—anything that could make a logo spin. Why did it need to spin? Because it could.

Accessibility often lost to the defining design question of the decade: “Can we make this text even more 3D?”

1997–1999: WAI and the first WCAG

On 7 April 1997, the World Wide Web Consortium officially launched the Web Accessibility Initiative (WAI) to develop standards and resources for an accessible Web. Tim Berners-Lee emphasized that the Web should be usable by everyone, regardless of individual capabilities or disabilities.

The industry needed systematic answers. What should happen with images and forms? How should keyboard interaction work? How could information avoid depending on color alone? And how could developers be persuaded not to name everything div1, div2, div-final, and div-final-final?

On 5 May 1999, W3C published Web Content Accessibility Guidelines 1.0. Its 14 guidelines addressed text alternatives, color, document structure, tables, and other foundations of accessible content.

Many now sound obvious. But this was an era when an entire navigation menu could be one clickable image with no alternative text. Good luck.

1998–2001: accessibility becomes a requirement

In the United States, Section 508 of the Rehabilitation Act played an important role. Following its 1998 amendment, accessibility of electronic and information technology became a concrete obligation for US federal agencies.

The argument shifted from “This would be nice to do” to “We have to do this because it is the law.” As the history of technology demonstrates, the second argument has a remarkable ability to accelerate a backlog.

The early 2000s: Flash and “Skip intro”

Flash enabled animations, games, presentations, and interfaces that were extraordinary for their time. It also enabled music. A lot of music. Sometimes it started automatically in an office with the speakers at full volume.

Dynamic custom interfaces posed a serious accessibility challenge. Native HTML controls exposed information assistive technologies could interpret. A handcrafted space-age button orbiting a company logo might not.

We still know this problem today. We just have frameworks instead of Flash. Progress.

2008: WCAG 2.0 and the four POUR principles

WCAG 2.0 was published on 11 December 2008. The Web had changed so much in nine years that accessibility needed an approach less dependent on specific technologies.

Four durable principles emerged, known as POUR. Content and interfaces must be:

  • Perceivable — information cannot depend on one sense alone, such as recognizing that a field has turned red
  • Operable — an interface that works with a mouse but not a keyboard is not accessible
  • Understandable — “Error 0x00239” does not explain what happened or how to fix it
  • Robust — content should work with different browsers, devices, and assistive technologies

POUR has endured because technology changes quickly. Human needs change rather more slowly.

2014: WAI-ARIA and application semantics

The Web stopped being merely a collection of documents and became an application platform. Developers built tabs, sliders, trees, comboboxes, dialogs, and widgets that early HTML authors had not anticipated.

On 20 March 2014, WAI-ARIA 1.0 became a W3C Recommendation. ARIA can tell assistive technology that an element is a button, a menu is expanded, an option is selected, or a status message has appeared.

Developers quickly discovered ARIA. Then they began adding it everywhere. This is why its first rule can be summarized simply: if a native HTML element provides the semantics and behavior you need, use it.

A button behaves like a button. A div role="button" is like a person with a sign reading “WIZARD” on their forehead. The assigned role does not give them magical powers 🙂

2014: the European EN 301 549 standard

The first version of EN 301 549, the European standard for accessible ICT products and services, also appeared in 2014.

This mattered because digital accessibility was expanding beyond websites to documents, software, devices, and services. Inaccessible technology no longer merely made an article difficult to read. It could prevent someone from transferring money, submitting a document, or using a public service.

That is where the jokes stop.

2018: WCAG 2.1 responds to the mobile world

WCAG 2.1 was published on 5 June 2018. Its 17 additional success criteria improved coverage for mobile devices and for people with low vision, motor disabilities, and cognitive disabilities.

Among other things, the industry acknowledged that an 8 × 8 pixel control can be difficult to hit with a finger. Shocking.

I remember the first hamburger menus on phones… I do not even know how to comment on that 🙂

2019–2025: the European Accessibility Act

The European Union adopted the European Accessibility Act (EAA) in 2019. From 28 June 2025, national laws implementing the directive began applying to covered products and services, including areas of e-commerce, consumer banking, e-books, payment terminals, and certain transport services.

Accessibility entered business through a door marked “compliance.” If “more people will be able to use the product” did not persuade an organization, “Legal would like a word” sometimes did.

2023: WCAG 2.2 and accessible authentication

WCAG 2.2 was published on 5 October 2023. It added nine success criteria concerning focus visibility, alternatives to dragging, target size, accessible authentication, and other needs.

If a person must memorize a 14-character password containing a capital letter, a hieroglyph, and the currency symbol of a nonexistent country—and then retype a code they cannot paste—we may have built less of a secure login and more of an escape room.

W3C's official WCAG 2 overview documents the dates and scope of each version.

Digital accessibility history: a timeline

  • 1984 — the IBM Screen Reader enables a computer to communicate information through speech.
  • 1990 — the ADA reinforces the idea that the environment, rather than the person, can create a barrier.
  • 1991 — the World Wide Web begins with mostly text, links, and semantic documents.
  • The 1990s — layout tables, text in images, animated GIFs, and “Best viewed in Internet Explorer.”
  • 1997 — W3C launches the Web Accessibility Initiative.
  • 1997 — HTML gets <label>. We spend the next three decades wondering whether we really need to use it.
  • 1998 — the Section 508 amendment strengthens accessibility requirements for US federal technology.
  • 1999 — WCAG 1.0 is published.
  • Early 2000s — the age of Flash, animated intros, and custom interfaces.
  • 2008 — WCAG 2.0 establishes the four POUR principles.
  • 2014 — WAI-ARIA 1.0 and the first version of EN 301 549 are published.
  • 2018 — WCAG 2.1 expands support for mobile access and diverse user needs.
  • 2019 — the European Accessibility Act is adopted.
  • 2023 — WCAG 2.2 is published.
  • 28 June 2025 — requirements implementing the EAA begin applying to covered products and services.

What can 40 years of digital accessibility teach us?

The history of accessibility is partly a history of repairing problems we created ourselves.

HTML gave us headings.

So we made headings from div elements.

HTML gave us button.

So we built buttons from span.

Browsers allowed text to be enlarged.

So we set a container to exactly 600 pixels high with overflow: hidden.

We gained control over every color.

So naturally we chose #aaa on #fff.

Then an entire discipline emerged to explain why those decisions might be a problem. Accessibility matured alongside the internet.

It was first treated as a specialist solution for a special group. Then as good practice. Next as a standard. Later as a legal requirement too. Today, it is increasingly understood as an ordinary feature of a well-designed product.

An accessible button is still a button. An accessible form is still a form. An accessible online store is still a store. More people can simply use it.

And perhaps this is the most important lesson from more than 40 years of digital accessibility:

Users should not have to adapt to our interfaces. Our interfaces should be designed for everyone—including people who cannot see, cannot hear, do not use a mouse, cannot distinguish some colors, experience tremors, or need more time.

Or are simply trying to buy a ticket one-handed on a crowded bus with sunlight shining directly onto the screen.

Ultimately, the history of digital accessibility is not a story about WCAG. It is a story about remembering that there is a person on the other side of the interface. And sometimes that person is sitting in front of an inaccessible app and reacting exactly as the rest of us would 🙂

A personal closing note

I genuinely enjoyed taking this journey into the past, researching these stories, and bringing all this information together. It helped me understand many things more clearly and brought back memories from years ago. I hope you enjoyed the journey too.

Official sources

FAQ

When did the history of digital accessibility begin?

Its roots predate the World Wide Web. One major milestone was the 1984 IBM Screen Reader, developed in part by blind programmer Jim Thatcher, which enabled blind people to receive computer information through synthesized speech.

When was the first version of WCAG published?

WCAG 1.0 became a W3C Recommendation on 5 May 1999. Its 14 guidelines covered topics including text alternatives, document structure, the use of color, and accessible tables.

What is the difference between WCAG 2.0, 2.1, and 2.2?

WCAG 2.0 established the four POUR principles. WCAG 2.1 added 17 success criteria, particularly for mobile use and people with low vision or motor disabilities. WCAG 2.2 added 9 criteria addressing focus, dragging, target size, and accessible authentication, among other needs.

What does POUR mean in digital accessibility?

POUR stands for perceivable, operable, understandable, and robust. Content and interfaces must be available to the senses, possible to operate and understand, and compatible with different browsers, devices, and assistive technologies.

Does WAI-ARIA replace semantic HTML?

No. WAI-ARIA can provide semantics for complex widgets, but native HTML should be the first choice. A button includes built-in semantics and keyboard behavior; a div with role=button requires developers to recreate that behavior correctly.

Why does the history of digital accessibility still matter?

It shows that barriers are usually created by design decisions, not by users. Accessibility is now a quality standard, part of good user experience, and a legal requirement for some products and services.