I am presenting at Ottawa's first Accessibility Summit. It's a 20 minute presentation on Fixing Accessibility Problems at the Source which I am using to talk about Drupal's experience trying to meet WCAG 2.0 AA.

The slides from this event are available on slides.com, a neat service that works nicely using the open source library reveal.js. I totally loved that I could both edit the HTML directly in the interface and also import/export and host my files wherever I wanted to.For my Accessibility Summit Slides.

I am including my notes here as part of this. Hopefully people will be tweeting using the hashtag #a11yopen as part of which, in which case I will try to capture the tweets and include them here.

Fixing Accessibility Problems at the Source

Good afternoon. The late theorist, designer and inventor Buckminster Fuller, said:

“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.”

I am going to assert that we've been approaching the problem of web accessibility from the wrong angle now for much of the last decade. We’ve been fighting within a hard nosed, fast paced, global, high-tech industry and despite all the best of intentions, accessibility advocates can’t possibly keep up. For a more inclusive Web, we need to build tools which by default are accessible to all.

First though, to introduce myself, I am the president of a small web development company here in Ottawa. We specialize in Drupal, which is a popular open source Content Management System (CMS). Drupal is presently driving about 2% of the entire Web. I've been very involved in improving the accessibility of this CMS for the last five years.

You can find out more about me via Twitter @mgifford or my website openconcept.ca. A transcript of this talk will be available on our blog. If you would like to tweet about this session, please use the hashtag #a11yopen.

I'd like to quickly describe the images I am using with my slides for the benefit of those people who may have difficulty seeing them.

Transformer

This first one is of a 60 foot high robot in a Japanese park. It is entitled, Scaling Matters.

Scalability is the ability of a system to be enlarged to accommodate growth. The Internet has proven to be very scalable, with over 200 million active websites on the Internet. It is estimated that Google has indexed over 50 billion individual web pages. With this amount of data, we simply can’t address the problems page by page. Any effective solution to improve accessibility on the Web needs to be able to scale very quickly.

The standard methods of addressing Web Accessibility problems can be boiled down to 4 main approaches:

1. Through better Assistive Technology (both browsers and screen readers)

2. Via improved standards and legislation (the AODA - Accessibility for Ontarians with Disabilities Act is a great example)

3. By firefighting problems with individual websites

4. And through ongoing education via blogs, or seminars, or videos, or webinars, or books.

We are seeing more tools making it easier to quickly review your site for basic accessibility problems. There are accessibility themes and plugins that can be added to your CMS. None of these take effect without an administrator making a deliberate attempt to improve their site’s accessibility. There will only ever be a small fraction of sites using these tools and they will always be playing catch up.

These are great methods which advocates have fought for and are continuing to build on, but none of them scale fast enough to keep up with the rapid rate of change on the Web. They all rely on keen individuals becoming inspired to fix a limited piece of a complex problem.

In contrast, as an example of scaling up, since the release of Drupal 7 a Chrome browser update broke some keyboard only functionality. The Drupal community is working to fix this new problem. When that gets into a future Drupal Core update it will automatically be implemented by hundreds of thousands of web sites around the world. To make an accessibility change at a scale this large using any of the standard methods would simply not be feasible.

Library

My next slide is of an old library. I added this image as the modern Web is built with libraries. Now you may not have thought about software this way, but the Web has really become so complicated that almost everything is built leveraging existing software libraries. Every step of browsing a website involves them.

Web pages started out being single HTML files with embedded images and links. This was the reality of the Web when the Web Content Accessibility Guidelines (WCAG) version 1.0 were being written. Most websites are no longer built this way, but use common Cascading Style Sheets (CSS) to deliver a consistent look.

Furthermore, much of the interactive functionality we’ve come to expect in modern sites is delivered through a browser side scripting language called Javascript. Many Javascript libraries have become so standardized that it has become a best practice, to simply load common ones directly through a Content Delivery Network like Google Hosted Libraries, rather than serving them them directly on their site.

The complexity of delivering your content to a wide range of web enabled devices has created the need for Design Frameworks so that a web page looks good on smartphones, tablets, and monitors.

CMS's involve all of these elements.

When software libraries are commonly shared across many sites, improvements are scalable.

Software that is scalable includes popular CMS’s, design frameworks, as well as Javascript libraries. I’ve highlighted just some of the popular ones, and most web professionals will recognize the names of these libraries. Wordpress, Drupal, HTM5 Boilerplate, Twitter’s Bootstrap, jQuery, Modernizr, JW Player, MediaElement.js. These are the percentages of sites that use these open source libraries according to BuiltWith.com. Accessibility fixes in these software libraries can suddenly affect millions of sites.

Open Source

This slide is part of an 2006 awards event organized by Google and O’Reilly. Open source or free software comes without a licensing or royalty charge, but that is just a small piece of why it is different from proprietary software. Open source software is built with ideals of a free culture.

You are free to:

• Use it for any purpose

• Modify it as you wish

• Share it with others

• Contribute Back

Kittens

The current slide is of a bunch of kittens, dressed in clothes, and playing with string. Is any presentation about the Internet complete without cat photos? I think not! I bring this up though because so many of the libraries used to create the Web are made using free, open source software. One of the most commonly recognized open source programs is the FireFox browser.

If you do a search on open source software, you’ll find a lot of comparisons to free speech or free beer. I prefer to compare it to free kittens. With any software, if there isn't a community around supporting its development it will not continue to grow.

But for features to be added and bugs to be fixed, people need to invest time into addressing problems. Lots of institutions have chosen to customize open source software in order to meet their short term needs but don’t share their enhancements back to the original developers. With an open license they are free to do this.

In the long term though it becomes more expensive since the problems don’t get addressed at the core. Organizations who care about accessibility need to find ways to give developers the resources they need to make these central libraries more accessible. When these libraries are built with accessibility by default, then the millions of sites that use them will just inherit these best practices.

People are often not in a position to contribute money to projects, particularly in big organizations. However, with open source communities, contributions can come in the form of bug reports, feature requests, documentation, design, UX, editing, testing, and much more.

With larger projects there are often events one can attend or sponsor. Participation in these events can help find other ways to get involved in making the software work well for everyone.

Drupal

This next slide is the Drupal logo imposed on the photos of some of the Drupal 8 Core contributors. As you can see, the Drupal community is now so large that it doesn't nicely fit one slide.

There are over 2,000 people who have contributed to Drupal 8 Core. It is estimated that over the last decade more than 300 person years have been invested in this project which would put the market value for this software over $16 million dollars. This is just Drupal Core and doesn’t include the 20,000 other contributed projects on Drupal.org that are also available for free.

As the owner of a small business, I was able to spearhead significant accessibility improvements in Drupal 7 and 8 and also raise awareness in this large global community. There are over a million sites now running with Drupal and it is particularly prominent in the government and educational sectors.

The Australian government announced earlier this year that they are moving all of their websites to Drupal. In the USA, at least 25% of federal government agencies are using it. I’d just like to highlight just four sites of interest - Ottawa.ca, Ontario.ca, ActionPlan.gc.ca, Whitehouse.gov

Likewise, in an American survey, 71 out of the top 100 universities in the USA use Drupal. A high portion of Canadian universities are also using it. Again I would like to highlight some relevant examples library.carleton.ca, UOttawa.ca, McGill.ca and UWaterloo.ca.

The Drupal community has done a few things differently which has made us one the most accessible enterprise CMS available.

1. We don’t see a distinction between front-end/back-end accessibility. We work to eliminate barriers to involvement at all levels.

2. Accessibility isn’t seen as an add-on, but rather as part of the default.

3. In Drupal 8 we are leveraging a lot of libraries that are Built Elsewhere like CKEditor and jQuery UI. We work to fix accessibility problems upstream if possible, making more tools accessible for everyone.

4. There is an understanding in Core developers that this is a complex issue and that it’s not something you can just fix.

5. The Drupal governance process is that of a meritocracy so ideas get debated and discussed until there is a sufficiently good resolution.

Does that mean that Drupal is accessible? No. It just means we’re more accessible than we were.

Electric Bean

My next slide is of the Cloud Gate sculpture in Chicago. Perspective has a lot to do with how we see the world. People often ask if a website is accessible, but this is a pretty meaningless question. The diversity of humanity doesn’t fit nicely into checkboxes. Furthermore, if something is accessible today, it may not be tomorrow. Will the next upgrade of Chrome, or whatever, break your website? So the question that should be asked is “How is your software accessible?”. What are the processes that are set up to help ensure that a piece of software is able to keep up, especially on the Internet.

In the Drupal community we have:

• Involved programmers with disabilities

• Reached out to browsers and AT vendors

• Used automated testing tools (such as WebAim’s WAVE, QUAIL)

• Contacted subject experts about challenging problems

• Have an open/transparent issue queue

• Make accessibility part of the whole development cycle

Bucket Bike

This is a slide with a woman cycling through Amsterdam with kids in a bucket bike. I was there last year and this type of sight is pretty normal in the central parts of the city. It’s hard to imagine a city looking like this in North America, but this only happened in Amsterdam and Copenhagen because urban planners started thinking of bicycles first and cars second. They then built the infrastructure to keep cyclists safe and save lives. It is this thinking that also needs to be brought forward into web accessibility.

Comparing web accessibility with physical accessibility, we all know that access becomes easier when improved building codes are implemented. The same is true with improving software libraries, except there is no legislation how these changes to infrastructure are done. Some changes with physical access can take years or even decades to implement (although there benefits can last much longer). Online changes can often be realized in a few weeks (but there will probably be new accessibility challenges next month).

It does take an intentional and ongoing effort to improve this infrastructure. In Copenhagen bike infrastructure receives millions of dollars worth of investment every year. At the moment what percentage of your organization’s accessibility budget goes into long term, sustainable infrastructure development vs. simply continuing to fill the accessibility potholes?

It is easier to create positive changes in a software community when there is

• A precedent to point to

• A culture of personal agency, “I can fix this!”

• Supportive and inclusive communications

• A team with reasonable expectations and that is tenacious

• Individuals who just won’t settle for the status quo

SpaceX

This is a slide taken from the International Space Station of the SpaceX cargo capsule that docked as part of an effort to rethink how humans are getting into space. You probably overlooked this piece of history if you weren’t a space buff, but it is the result of a remarkable challenge to rethink a big technical problem. The space industry needed to find new models to make it more cost effective to get humanity into space as the approaches taken by NASA were no longer affordable.

These technological advancements in space exploration are significant, but this type of innovation is happening all the time on the Internet.

More information is being served through the web than ever before. Pages are becoming increasing complex and every year there are more activities people are doing online.

Given this reality, the accessibility problems that people are struggling with are simply too big for organizations to take on in isolation.

The Government of Canada’s Web Experience Toolkit is the only design framework that I know is tested regularly to ensure that it still meets WCAG 2.0 AA. Browsers and Assistive Technology are changing so rapidly this should be normal for anyone who is required to meet WCAG standards. Furthermore, user expectations are changing as more websites become interactive.

Working with open source communities makes it possible to keep up with this rate of change because the responsibility of identifying and fixing accessibility barriers can be shared across multiple institutions.

Another really important change comes down to agency. People with disabilities can become engaged in creating the solution to barriers that they face on the Web. There is no financial barrier to developing software with an open license, the community is generally quite open to feedback, questions and even to bug reports. For people with disabilities who become involved in open source projects it can become a window to other work such as project management, usability, software development, information architecture and more.

Only by thinking through the source of common barriers, we can find ways to eliminate them. Only by sharing best practices and engaging with people with disabilities are we going to find viable solutions.

By building a new model that deliberately works with open source communities we can more effectively build an inclusive web experience.

I would like to leave you with a small challenge. As people who are passionate about accessibility, identify what open source libraries you are already using as part of your infrastructure. Are there ways you can contribute back to them in order to make them more accessible?

I look forward to hearing the questions at the end of this session.