Thursday, July 2, 2015

Future of Web Editing: Proactive versus Reactive Compliance

I went to my brand new medical specialist the other day, and like with any new client, he asked me what I do for a living. I told him I was a web designer and developer. He remarked that he has a website and someone who works on it, but he knows how busy the developer is, so he thinks he should update the website himself.

This is a response I hear quite often from across the campus. Only a decade ago, everyone with a computer connected to the Internet was getting into the latest web editor they downloaded and sprucing up webpages related to their work and hobbies. And we all called ourselves “Webmasters.”
It was simple enough, right? After all, it is technology, and technology is supposed to be smart enough anybody can build a webpage.

Supposed to be.

But it isn’t.

And that was the shock I received at the first accessibility conference I went to a decade ago. Anyone can build a webpage with the numerous drag and drop options available, however, most are not aware of the accessibility challenges, not to mention content strategy or information architecture. We can do a lot with technology, but technology is only as good as what we put into it. Without the proper knowledge, web maintenance is becoming a far more specialized practice only individuals with a minimum set of technical skills qualify to accomplish.

Our goal as we progress is to make it easier for less technical staff to maintain websites and help technology literate staff keep up with compliance standards at the same time. A new strategy we will be implementing will use a technique commonly used on word processors.

Think back to the days of the typewriter. Yes, they still exist, and their sound is unforgettable to those of us who have used them, but you may recall the typewriter never told you that you misspelled a word.

Yep! You remember reading through your work and cursing under your breath as you had to start all the way over. Well, that is unless you had one of the newer typewriters that let you go back and erase a typo. And it improved through various intervals until we started typing on computers in these technological contraptions called word processors.

Example of a word processor warning a user of a misspelled word.

Then they got really smart! They started to warn us about our misspelled words! Eventually, they were programmed to figure out what we intend to say despite our poor typing skills, and now they autocorrect text for us.

The same kind of proactive warning system has not been done to make web content accessible. For example, web maintainers remember their days writing research papers and using underlines for the titles of books. However, underlines on the web are used primarily for links. People often get confused about what is a link and what is not when they see the underline, imagining they will perhaps hit an online store selling that book only to click on a non-reacting webpage. Web maintainers receive no warning when they underline text for web content telling them they are using the style inappropriately.

This means what I do right now checking our website for accessibility compliance issues is very reactive. I go through webpages manually to check if web maintainers are inappropriately using the underline style for web content. Then I tell them where the problems are, why underlining content that isn’t a link is inaccessible, and ask them to remove the style from their text. I have a very large website to scan and it is very slow process. And that is only one piece in a very long checklist of accessibility compliance issues!

However, with Project Squishy, we will be improving all that in two ways:

1. Appropriate Styles and HTML Tags

Example of Cascade Server's WYSIWYG warning a user of an inappropriate style in use.
Many of the styling errors that web maintainers make currently will have warnings appear around them as they use styles inappropriately, just like a spell check or grammar check. If the maintainer does not correct it in the WYSIWYG editor, the content will still not appear with the styles they had placed on the text when they publish the page to the live website.

This also goes for HTML tags that have been deprecated, such as the old acronym tag (see the full list of HTML 5 tags, plus the alternatives for deprecated tags).

2. Properly Structured Page Content, Alternative Text, and Appropriate Writing for the Web

Preview mode in Cascade shows a warning for the text that was inappropriately styled along with the reason and options for correcting the issue.
Previewing a page inside Cascade will show a warning for many more issues that are inaccessible, including missing or inappropriate alternative text, bolding or italicizing of entire paragraphs, and using headings to increase the font size of entire areas of content that should be paragraphs.

These issues will only appear in the Preview mode inside Cascade Server, along with the reason and options to fix it. When maintainers publish the content without fixing the accessibility issues, the content in violation will not publish.

It will also autocorrect inappropriate spacing and punctuation.

I’m working on more issues as Cascade allows me to resolve them within the system in order to provide maintainers the quickest turnaround on accessibility compliance checking. This proactive approach will help web maintainers receive immediate warnings of inaccessible content issues as well as teach them what to do without me having to review the content and write responses each time.

The Future of Proactive Accessibility Checking

My solution inside Cascade Server is not a full accessibility compliance check, but it is a step in the right direction for all of us. Many things will still need manual checking, and web maintainers will still need training on how to make content more accessible, just like we did when we learned how to write research papers on typewriters.

I do see some potential areas for technology, on its own, to catch some of our mistakes. For example, we cannot insert an image into a webpage and generate automated alternative text for it based on what is seen in the image currently. However, The Wolfram Language Image Identification Project is making some major strides in image identification such that if we were able to implement it into web editors, we would, at minimum, be able to generally describe images based on what their databases believe all those pixels in their specific pattern on the images represent.

The only problem with this is similar to problems with textual autocorrection. Does the alternative text accurately describe the mood or intention of the web maintainer who inserted the image into the page? What about artistic expression? Yes, we will all be laughing at the funky automated identification responses just like we already do with textual autocorrect from our “smart phones.”