I had the pleasure of being on AXSChat talking about web accessibility and Drupal in October. It was actually a two stage process as Neil Milliken and Antonio Santo had a really fun video conversation on the Friday before. Unfortunately, Debra Ruh was not able to join us for the video discussion. That was captured and captioned and uploaded on the weekend. Then on Tuesday, October 23rd, we had an hour long Twitter discussion flooding the Twitterverse with questions about accessibility using the hashtag #axschat. You can watch the video here:

But thought that it might be interesting to link back to some of the questions & answers here in this blog post.

Q1 What is the impact of authoring tools like Drupal on the inclusiveness of the web?

According to Builtwith Drupal accounts for over 1 million sites, Joomla! has about 2.5 million sites and WordPress is close to 27 million sites. That is a huge part of the public web. By influencing those 3 open source CMS's you're able to shift over 1/3 of the web. 

Open Source authoring tools like these are influential since they shape the adopted defaults. If they have good accessibility best practices developers are more likely to adopt them.

Investing in the accessibility of a large open source projects means that you can actually begin to define them. By working in the open to address specific problems the community is able to build a robust solution.

Q2 Drupal takes a Community based approach to accessibility. How is that different from in other parts of the IT industry and what are the benefits. 

To illustrate one way open source communities are different than proprietary ones, look for an open issue queue. All known accessibility issues in Drupal are in this issue queue https://www.drupal.org/project/issues/search?issue_tags=accessibility. This makes it easy to identify if it is my problem, or a broader issue to be fixed.

Now some proprietary tools like JAWS now have an open issue queue but this is a new thing. Before this one could submit an email, but never know if a problem was unique to your system or something more global. 

By having it in the public it is findable, even using a generic Google search. People can point to it and link together attempts to address this problem in other projects. The web is an ecosystem, so often you need to point to browsers & assistive technology issues. 

Given that the web is evolving, it is an accessibility best practices is to engage a bigger community. Human behavior and software libraries keep changing and very few can keep up. By working with an open community, we can keep finding better solutions over time. 

Q3 What changes to how we procure IT do you think would help make good web accessibility easier to achieve & maintain?

We have to push beyond the simple line "The deliverable must meet WCAG 2.0 AA" because it hasn't worked. This has been in boilerplate contracts for the last decade and it isn't clear that people with disabilities are further ahead. Accessibility is a journey, not a destination. 

Ultimately it comes down to demonstrating that the client is:

• committed to accessibility,
• their project team is onboard and doesn't expect it to be a "free" addition,
• and that the work of the vendor may be reviewed by a 3rd party accessibility evaluator 
   

I have a list of good procurement guidelines that are compiled. The responsibility should be shared between vendors & clients. Clients need to be doing quick evaluations of their vendor's sites for accessibility. 

Q4 Open source is free, which is one reason that so many people use it. Why is Open Source approach to creating software such a valuable asset for accessibility? 

Now let me first get to your comment on free.  The estimated cost of creating Drupal Core is currently USD $31,224,482 according to openhub.net. So it is very valuable even though you don't have to pay anything to use, modify or distribute it. 

For accessibility though Open Source is huge. You don't have to wait for your issue to become a priority for a senior executive sitting in Seattle. There is nothing from stopping anyone from getting involved & raising concerns about issues that bother them. 

Now posting a bug isn't going to get an issue fixed (although it might). It is useful to get involved in the community. To keep nudging issues you care about ahead. Sometimes it is easier to fix the problem than to have it show up in the issue queue again. 

The other thing is that most Open Source projects also are keen on Open Standards. Developers like to be following best practices. Point to the W3C's WAI guidelines and explaining how to repeat the problem may be enough for developers to remove it.

For People with disabilities, getting engaged with open source communities will help to:

• educate a lot of young people developers about disabilities
• provide useful job skills in communicating technical issues
• actually fix many barriers 

Q5 in our video interview with Mike we touched on the importance of engaging accessibility at the earliest opportunity in the development cycle. Why is it crucial and what is the impact of delayed engagement? 

It is common known that it is easier, more effective & less money to address accessibility as part of your agile process. Delaying an  accessibility review generally means that there won't be time or budget to address issues.

We consider the framework we are using before even beginning the project. We know we can leverage a lot of Drupal's built-in accessibility. We know that there will be a lot of functionality we can rely on someone having looked at. 

When we are just exploring a new module or theme for use with a client we try to do a quick accessibility review. Even if the we haven't won the work, it can be useful to post to their issue queue about problems I have found. Sometimes the community fixes them before we need to install them.

The longer the delay for accessibility issues, the less likely that there will be time to find a solution. Yes, you can find a fix to make it work for IE11 & JAWS, but is that at the cost of NVDA & Chrome? Do you have time to test?

Q6 How can publishing tools make it easier for people that are not accessibility aware to produce content that is inclusive? 

Thanks for lining up the Authoring Tools Accessibility Guideline (ATAG), question for me. This W3C Guideline was lead by Canada's Jutta Treviranus. She and others at the IDRC wanted to help authors write better, more inclusive content.

ATAG 2.0 is a guideline that is often overlooked because it is hard to put in place. The concept behind it is quite simple. Any authoring tools should be accessible to everyone and should help make it easier to produce better content. 

Drupal's admin interface has been pretty good ever since Drupal 7 thanks to the efforts of folks like Everett Zufelt. Everett argued for both front-end & back-end accessibility back before it was cool. It is now even better in Drupal 8.

For the authoring interface we have added elements from ATAG 2.0. As an example, alternative text (alt text) is required by default for images. We have also enabling spellcheck by default in the WYSIWYG. We chose CKEditor as a WYSIWYG partly because they have already done work on accessibility.

There is a lot more to do to assist authors. We have:

• added help text to make accessibility enhancements more discoverable, ​​​​​
• ​​ensured authors are given access to insert captions & summary elements into tables,
• tried to assume best practices where we can. 

I would love to see Drupal using Machine Learning to suggest to authors what alt text they might use or finding ways to incorporate a Plain Language algorithm to highlight ways to simplify text. Hopefully this will come.

But it won't come until people start investing in fixing the problems with the core libraries. Common open source libraries are used by much of the internet. Right now the vast majority of the resources on accessibility go into site specific remediation. If we continue this way accessibility will always be a burden.