[META] W3C validation for Drupal Core

Dom., do you know about the Drupal Accessibility Group? Ever since Drupal 6, we have been working to help developers make Drupal conform with the W3C's Authoring Tool Accessibility Guidelines (ATAG). To conform with ATAG 2.0 would mean that:

• The administrative interface of Drupal conforms with WCAG 2.0. (We want it to conform at Level AA.) This means that Drupal is an accessible tool for anyone to use to develop websites, applications, or whatever else they feel they can build with it.
• As people use Drupal to build stuff, it guides them as much as possible to do it in a way that makes whatever they build accessible. For example, consider this simple case:
  • A person working on a Drupal website loads an image to a page.
  • One field in the interface for loading the image prompts them to enter the correct alt attribute.
  • Three radio buttons under that field are labeled, respectively:
    • This image conveys information. (This button is the default selection.)
    • This image is decorative, not meaningful.
    • This image is being loaded to a library, not a Web page.
  • Next to the field is a link labeled "Help" or "Explain 'alt text'."
  • If the person clicks that link, they will learn:
    • Alt text mainly helps people with screen readers understand images.
    • If they leave the default button selected, they must complete this field with the word or phrase they expect a sighted person to think of when they see that image. The screen reader will announce those words when it encounters the image.
    • If they select the second button, the alt attribute of the image will be alt="", which tells screen readers not to even say that the image is there.
    • If they click the third button, they must complete this field with a description of the image so a person who is using a screen reader and wants to download an image from that library will know what they are downloading.
  • To upload the image, the person will have to have selected the right combination: Either the first or third bullets, with alt text, or the second bullet, with no alt text.
  • When they successfully finish the process, the confirmation message shows them the HTML resulting from their actions and describes for them the circumstances under which that HTML would be accessible.
• The site administrator can control the options presented—for example, if this is a place where the image will always fall into one of the three categories, hide the radio buttons and give the corresponding support:
  • If this is a place where only meaningful images are to be added, prompt the user to enter the text replacement for the image into the field for the alt attribute.
  • If only decorative images are loaded with this interface, hide the whole dialog about alt text.
  • If the page is an image library, prompt the user to enter a short description of the image, and tell them that the purpose of this description is to let people who are blind know whether that image is what they're looking for.

The scenario I've described above is not necessarily the perfect result, but I hope you can see the general point. There is usually no way a content management system can tell why an image is being added, so it can't tell whether the alt attribute should be empty or populated. And even if the alt attribute is populated, the system can't be sure the person uploading the image entered appropriate wording.

But the system can help people understand that every image must have an alt attribute and what they should consider when they decide what wording will go into that attribute. So it can't ensure that a website built with Drupal is accessible, but it can ensure that people who use Drupal to build websites know what they can do to make their websites accessible.

We're working now to ensure that Drupal 8 conforms with ATAG as well as it can. And I must admit that I've been almost completely absent since the release of Drupal 7, but I'm returning. For the latest word on accessibility and Drupal, contact Mike Gifford (mgifford), our accessibility maintainer for Drupal 8, or Jesse Beach (jessebeach), another of the organizers of the Accessibility Group.

I am very glad to see that you are interested in making Drupal more accessible, Dom. You might also review the issues that are blocking the release of Drupal 8 to see which ones relate to accessibility and whether you can help with those particular issues. That's a place to make a huge difference.

Welcome!

Dom., it looks like you've used an automated report of some sort to identify errors in Drupal core. Unfortunately, not all errors can be caught in an automated check, and not all errors reported by an automated check are necessarily errors.

We do have an Accessibility Team that reviews patches and other code that touch accessibility in some way. I've added two tags to this issue:

• "Accessibility," because it's intended to make Drupal work better for people with disabilities.
• "needs accessibility review," because as an accessibility issue it does need review by the Accessibility Team.

For better response to issues you create that are related to accessibility, please be sure to add these tags.

I'm glad you're eager to help us make Drupal an even more accessible development platform. Thanks for contributing!

Just quickly wanted to add that the "needs accessibility review" tag isn't reviewed as much as the "accessibility" tag.

Also wanted to add that the W3C validator has flaws in it like all accessibility testers. Automated testing only goes so far and each has it's limitations & biases. They test for the low hanging fruit of WCAG for the most part. Things like alt tags which are easy to programmaticly determine.

I'm really happy though that you've set up https://www.drupal.org/project/w3c_validator though. Excellent job.

Thanks.. Hopefully we'll get you some help to fix up the module.

Thanks @Dom. not sure how many of those are accessibility issues vs best practices.

Certainly duplicating html5 & aria isn't good. Would be worth setting up a new issue to clean up the html in 8.1

I added a follow-up to remove unneeded role="navigation" attributes: #2655764: Remove unneeded role="navigation" attribute from <nav> elements

And another one for <button role="button">: #2655772: Remove unneeded role="button" attribute from <button> elements

And the last one: #2655794: Remove redundant WAI-ARIA role attributes from <main>, <nav>, <aside>, <header>, and <footer> elements

@Dom. what does the W3C Validator provide that tools like HTMLaw? - https://www.drupal.org/project/htmlawed

Ok, this is fine @Dom. It sounds like ultimately they are are accomplishing similar things. Both are aspects of accessibility.

It would be great if we were scanning our sandbox environments to catch bugs that the validator finds.