Nature abhors a vacuum—particularly when it comes to to-do lists and worries. No sooner did I complete the big SentenceWeaver upgrade and deal with (at least for now) the various bugs that have sprung up during beta testing than I found myself worrying about a whole new issue: one that potentially undermines the entire program. This issue stems from a certain shadowy, world-wide organization that has the power to cause widespread disruption to websites.
No, it’s not Korean hackers. As far as hacking goes, I’m not particularly worried. My content is copyrighted; my code is encrypted; whole directories are blocked off from all IP addresses except mine. Then there are my web host’s gatekeeping algorithms, which are so risk-averse that they recently started blocking the IP address of my main beta-tester. A few of the thousands of words he’s typed in, as it turns out, appear on my host’s list of key words that could theoretically be used in attacking the website.
(This list includes “from” and “where”: words that appear regularly in the sentences that users input as part of their grammar training. The offending sentence, the one that got my user backlisted, was “The boy and the girl will wash the car three days from now.” Once I became aware of the issue, the solution was a simple string substitution before and after the php calls to the database.)
No, the shadowy world-wide organization to which I refer is the World Wide Web Consortium, aka the W3C. This is an organization of organizations, founded at the MIT lab for Computer Science “with support from” the European Commission and DARPA (the Defense Advanced Research Projects Agency). Its member organizations, which must be “reviewed and approved” by the W3C, range from businesses to universities to “governmental entities.”
The W3C’s mission, according to Wikipedia, is:
to foster compatibility and agreement among industry members in the adoption of new standards defined by the W3C. Incompatible versions of HTML are offered by different vendors, causing inconsistency in how web pages are displayed. The consortium tries to get all those vendors to implement a set of core principles and components which are chosen by the consortium.
In service of this goal, the W3C has adopted new standards for HTML5, the latest version of HTML that all browsers are eventually expected to use (think psychiatrists and the DSM V). One of these new standards involves “deprecating,” or no longer supporting, any HTML code that the W3C views as purely “presentational” in nature (think Asperger’s Syndrome).
One of these deprecated elements of HTML code is the lowly font tag—the tag used to specify aspects of font text like font type and color. In the words of the W3C’s website:
The element is a non-standard element.
HTML5 classifies it as a non-conforming feature.
HTML5-compliant websites are instead supposed to be handling color via Style Sheets.
If your website’s presentational elements are static, that’s fine. Indeed, in most websites, things like font type, font weight, and font color don’t change when you interact with the site. But one of the things that makes SentenceWeaver special—and is, in fact, an essential part of its Feedback Algorithm—is dynamically generated font color, as we see in this video below.
The prospect of my entire program, within the next few years, losing an essential part of its functionality, first kept me up at night—and then propelled me towards a workaround. Implementing it took me about a day and a half, and though the changes in code, in the end, probably summed to just a few extra lines, it was a kludgy pain in the neck.
One of the problems with shadowy, unrepresentative organizations inflicting rigid standards on the rest of us is their tendency to forget about unintended consequences. What we see here with the W3C, in particular, is a failure to imagine all the creative ways in which web tools can be used. Deprecate something, however lowly and insignificant it may seem to you, and suddenly algorithms you never thought to think about stop working, perhaps requiring many hours and kludges to rewrite.
The best defense of the W3C’s rigidity has to do with accessibility for people with special needs. The more rigid the standards for webpages, the easier it is to plug in accessibility tools like screen readers. But in my world, this is yet another example of accessibility at all costs—of ignoring the tradeoff between accessibility and remediation.
In my writings on disability in the classroom, I’ve worried that the emphasis on accessibility—along with the proliferation of assistive technology—has diminished the urgency of actual instruction. If students can communicate all urgent messages via picture buttons on tablets, why invest so many hours in teaching them to communicate with words?
The W3C standards put a different spin on this tradeoff: in prioritizing accessibility over website dynamics, they’ve undermined at least one program that caters to special populations as much in terms as instructional needs as in terms of accessibility.
Catherine & Katharine 