Well, it’s back: The Accessibility Directorate of Ontario’s standard for information and communications has been semireleased for semipublic “review.” This standard is, of course, one of those standards being created under the ægis of the Accessibility for Ontarians with Disabilities Act (AODA).
I say semireleased because it isn’t on the Directorate’s Web site. A member of the committee, Sharlyn Ayotte, published it on her blog, with a call for comments. This is hardly transparent government in action. This committee has barely been able to get its act together enough to post committee minutes from 2008 (only one set of such minutes is up), so it isn’t surprising that a version of a public standard meant for public comment would be hidden from public view.
Is that mere incompetence? No, it’s actually worse, because once this standard gets enacted, if you live or do business in Ontario it will apply to you, if your organization is large enough or is otherwise covered. You may be legally required to do what it says. Do you know what’s in it? Well, thanks to Ayotte and me, you do. But no thanks to the provincial government.
This thing is still a mess. It’s just a different kind of mess than it was last time. The fundamental problem remains a lack of expertise on the committee roster. Practically nobody is an expert in “accessible communications,” and several who do have topic knowledge have conflicts of interest. Sharlyn Ayotte’s company stands to benefit from accessibility legislation. The perennially bumbling CNIB leaves no stone unturned in its quest to dominate every aspect of blindness in the country; CNIB relentlessly promotes itself as experts on everything from signage to Web sites, despite knowing nothing whatsoever about either. (These are the same people who commission research on large print, determine that no conclusions are possible, then publish a list of conclusions.)
Other issues?
The committee seems content to require adherence with specifications that are unfinished, like WCAG 2. But it isn’t interested in other relevant specifications, like the one for PDF accessibility, that are also unfinished. You can’t require conformance with a spec that isn’t finalized yet. If you’re going to do that anyway, you can’t play favourites.
In any event, reliance on unfinished specifications was called out in the July 2008 minutes as a problem. I am not expecting the problem to be fixed; I’m expecting they will forge ahead regardless and require adherence to WCAG 2 while ignoring every other finished or unfinished accessibility specification (save for DAISY, as you will see shortly).
There seems to be a basic misunderstanding of the provisions of the Ontario Human Rights Code. Employers and other organizations must accommodate people with disabilities up to but not past the point of undue hardship. There is no requirement that every person with every conceivable disability be accommodated if doing so would represent undue hardship.
In case you aren’t familiar with the term, undue hardship can be a financial calculation, but may also have to do with obstructing the fundamental nature of a business; it’s determined individually and there are no blanket rules. But the entire AODA spec attempts to accommodate every possible disability simultaneously and in every case without exception. Without even doing much investigation, it stands to reason that this would extend past the level of undue hardship some of the time or a lot of the time, hence would be impermissible under the Code.
To say the same thing another way, the AODA committee is overstepping its bounds and is going to get its asses sued off.
The effect on national and multinational corporations has not been considered. The specification, in its current form, essentially bans existing technologies like Google Maps and many off-the-shelf machines, terminals, and devices. This may or may not have been the intention, but the fact remains that national and transnational corporations have more money than God and would have no problem suing the province of Ontario to have the rules rescinded.
Perhaps the committee thinks its job is to establish a high-water mark instead of merely assuring accessibility. Perhaps it views itself as comparable to California, whose fuel-economy and emissions standards for motor vehicles set a worldwide high-water mark. (Even if the car you bought in your hometown doesn’t meet California specifications, chances are the carmarker engineered a version that does.) By any rational estimation, the committee would be overstepping its bounds if it acted this way. Its task is to assure accessibility for people with disabilities, not to teach companies a lesson they’ll never forget.
Additionally, the specification intrudes onto matters of federal jurisdiction, like copyright and broadcasting.
If my application to join the committee had been approved, maybe the spec would still be the mess it is today, but the committee would have heard about it up front and would have had to make a conscious decision, recorded in public minutes and other documents, to ignore my advice and screw it up anyway.
In disability law there is an established concept known as bona fide occupational qualifications or bfoqs. (For some reason, it is usually written in lower case.) There are some disabilities that categorically rule you out for certain jobs. The classic example? You can’t drive a bus if you’re blind. For bus driving, vision is a bfoq.
The spec makes no provision whatsoever for bfoqs. As written, every job, task, and morsel of “information and communications” has to be accessible to everybody, even if the purpose or function of that information requires a bfoq. By my reading, it would actually be impossible to present inaccessible Web content to a Web developer with a disability and tell that developer to fix it. Uncaptioned video would have to be given to certain disabled captioners with captioning already in place, even if that’s what the disabled captioner’s job is.
The absence of bfoqs is circular and nonsensical and is, additionally, a magnet for lawsuits.
In numerous places, the spec requires you to do things that the Copyright Act (a federal law) restricts.
This comes up in various places in the spec, mostly in the context of training or education. That’s bad enough and it is just not going to work. But libraries that provide “reference text-based materials” must also provide them “in accessible electronic format.” Essentially, libraries have to produce their own alternate formats for every reference book they buy, even if they don’t have the rights to do so.
Let me make this even clearer: The library cannot buy a new dictionary or encyclopedia without also buying some kind of electronic format, which, in this muddled specification, may or may not mean DAISY (see below).
Libraries get another kick in the groin: “Materials in situ shall be made available in accessible formats upon request.” It doesn’t say electronic formats, but if I walk into the Toronto Reference Library and “request” that its entire collection be turned into Braille, they have to do it. There is no limitation whatsoever on the “request.”
In particular, this means that a library has to caption and describe all its videos, which only the copyright holder has the right to do. (Captioning and description are derivative works.)
The specification is a confused mess on this topic, but from what I am able to gather, the only electronic file you can use to make a printed document accessible is “E-text,” that is, plain text files. You cannot use anything else – not valid HTML, not tagged PDF, and certainly not Microsoft Word or RTF. There are minor exceptions, but they are muddled and are probably accidents of slipshod writing.
Let’s go through the whole list.
New IT-based information and communication systems shall have an accessible user interface and content file format by default upon deployment or implementation.
Essentially, all applications in Ontario have to use plain text. The committee has obviously not considered the case of file formats that humans never read, like database files.
New content delivered through existing IT-based systems shall be available in an accessible digital file format.
Again, some “content” is designed only for computers to use. (The spec does not define “content.”)
“Accessible digital format” (not “file format”) is elsewhere defined as follows:
A digital format is an electronic means of transmitting information and is accessible when that format presents textual, audio and graphic information in a manner that allows the user to find their way, enables comprehension, anticipation and understanding of the data flow and organization of the material.
In theory this is a technology-neutral definition. In practice, it’s just vague.
When prepared information and communication is provided in a print format, the organization must provide... an accessible electronic format (E-text) of the document
You must provide plain text for all printed documents. You may not use other text forms that are not otherwise Braille, large print, or annotated.
What is E-text? It isn’t defined. Only its functions are defined:
Information provided as an accessible electronic file shall:
- a) be operable using current screen readers and text-to-speech applications,
- b) be searchable,
- c) use either ANSI/NISO Z39.86-2005 (also referred to as Digital Accessible Information System [DAISY]) as an intermediate format or an open standard that includes the structural elements of ANSI/NISO Z39.86-2005,
- d) provide a description of specific information conveyed by non-text content in the context of the document, and
- e) be provided in a media that is readily accessible on-line, or in a media available on the majority of devices reading electronic files.
In other words, your E-text has to work in all current screen readers (they used the plural; that means all of them, not just more than one); it has to be searchable (trivial, but that has nothing to do with the file format); and, finally, it has to be DAISY.
So in fact E-text is defined, except only by implication. I guess the committee does not realize it is requiring nearly everything in the province to be available in one specific electronic format. To make this even clearer, all your printed information must be available in DAISY. Can you produce so much as a leaflet in DAISY right now?
The requirement to provide alternate text is as badly written as discussions of alternate texts always are, and is not improved over the old version. I don’t know how many times I have to explain this: You do not want a description of images (“This here is a picture of a flower”), you want a replacement for them (alt="Hydrangea").
Almost any conceivable file format can be “a media” (sic) that is “readily accessible online.” I assure you that “a majority of devices reading electronic files” cannot understand DAISY. What kind of device doesn’t read electronic files these days? Do they mean my camera and its memory card? An Interac PIN pad?
But the spec has more to say about “electronic file[s]”:
When prepared information and communication is provided through an electronic file the organization must provide:
- a) Accessible electronic text,
- b) A Braille-ready electronic format,
- c) A spoken format, and
- d) A version in which the font size, contrast, spacing and method of highlighting can be modified to meet individual user needs.
For all your electronic files, even if they are already accessible or even if humans are never meant to read them, you have to provide another electronic file, a Braille file, an audio recording, and a “version” that has its own user interface. You have to provide all of those alternatives every time.
The committee seems unaware that “files” do not have display characteristics. A file is a file, not how it is displayed (QED). (Similarly, a file is a file, not how it is searched.) I don’t know of any system anywhere that permits random “modifi[cation]” of font and size and “contrast” (whatever that means) and “spacing” (intercharacter? leading?). Nor does every system permit “highlighting”; if you don’t provide a “method” for that, your system might be illegal.
Something else the spec makes plain as day: All printed publications must be available in accessible form. With what exceptions, you ask? For organizations covered by the specification, none. And there are broad-ranging requirements for publishers that essentially require “E-text” for all printed books in certain categories (“Publishers and other resource providers of text-based educational/training materials shall provide accessible electronic versions for use in alternative accessible formats at the point of order of the text-based version”).
When prepared information and communication is provided in a print format, the organization must provide:
- an accessible electronic format (e-text) of the document,
- a Braille-ready electronic format or Braille printout of the document,
- an accessible audio format of the document,
- an enlarged (large print) version of the printed information,
- an electronic version of the document with supports for comprehension
You must provide all five of those alternate formats.
What would an example of an inaccessible “audio format” be? Why isn’t this defined? Note that this permits a live reading in person.
The fix for this section?
The cost to the consumer with a disability for alternate accessible formats as required by any sections of this proposed standard shall be no more than the cost of the formats charged to other consumers.
If I sell a printed document for $5, the intent of the specification is to prevent me from charging a blind person $6 (or $5.01, or $999). As written, though, I am free to charge the blind person double: I can force them to buy the inaccessible version (at a price of $X) in order to buy the accessible one (also at a price of $X).
There is a conflict here with the Copyright Act, which enables a person with a print disability or a nonprofit organization working on his or her behalf to create an alternate format without prior permission. There is no requirement under the Copyright Act to have actually bought or even to have legally acquired or possess the inaccessible version. Some alternate-format producers insist you buy the printed book before they’ll produce an alternate format. There is no basis in law for that, but there’s no basis for its opposite, either.
Today, though, those producers might charge you the true cost plus markup for the alternate format. The AODA spec would make that illegal: Even the provider of an alternate format could never charge more than the price of the inaccessible version. This is a great way to put out of business everyone but the CNIB, with its vast millions, ongoing donations, and charitable status. Since CNIB is on the committee, I assume this was an unstated but intended outcome.
Where organizations provide individual accommodation as required by Ontario’s Human Rights Code, the organization shall[... g]ive the individual the same time to review, respond or use the information and communication for the intended purpose as given to others [and p]rovide the same availability in terms of time and place as is available to others.
This is the opposite of accessibility. If you have trouble with reading (or just with manipulating reading material), you will probably need more time, not exactly the same amount of time. The spec acts as though people with dyslexia (for example) were being given far too much time to read something, a situation the committee wants to nip in the bud right away.
(This whole thing comes up more than once in the spec.)
Organizations shall develop a policy and establish a practice and procedure on making information and communications available in plain language
Let’s say my organization is MARS, the medical-research cluster in Toronto. My “information and communications” may well include boilerplate Web content, newsletters, and the like, and maybe plain language is appropriate there. But all my scientific and technical reports have to be written for scientists and technicians. Sometimes there is no plain-language version of a document, nor is one possible. This is not the same as writing a script for a popular TV show about a scientific topic, where you really do have to use plain language; I’m talking about peer-reviewed research by scientists for scientists.
In any event, the committee has not advanced a rationale, backed up by research, for any requirement to use plain language. Even if it were able to come up with such research, there would still be too high a risk that something like literature would be banned because its “language” isn’t “plain” enough. (Impossible? Not if the spec remains as badly written as it is now.) Committee minutes from July 2008 admit that plain language as a concept hasn’t been worked out yet.
If you require a handwritten form, you have to provide four different alternatives at once. One of them is simply insane – “transcription of speech or speech recognition.” (Really? How will my printed application form transcribe your speech?) But you only have to provide these alternatives on request.
From what I can tell, this is one of the few provisions of the spec that kicks in on request. Obviously that was a mistake, since nearly everything else is mandatory in all cases without exception. (I predict this will be the only thing they correct in the next version; they’ll ignore everything else I’ve documented here and will do nothing but make this provision mandatory.)
Organizations shall establish processes for receiving and responding to user requests, feedback, and complaints regarding accessible information and communications.... The feedback and complaints processes must permit persons to provide their information and communications in their preferred format.
So a blind person is legally entitled to send in a Braille printout that sighted people cannot read? A big-D Deaf person has a similar legal entitlement to submit a sign-language video that hearing people also cannot understand?
What if my preferred format is an audiotape when nobody in the organization has a tape player anymore?
What if it’s DAISY when nobody there has ever heard of DAISY or has anything resembling the technical ability to play it?
All your videos that provide “prepared information and communication” have to provide the entire list of the following without exception:
- a) Synchronized captioning of the video,
- b) Synchronized audio description of the video,
- c) Text transcript of the visual and audio information communicated by the video, and
- d) Synchronized interpretation of the speech and audio in ASL or LSQ.
In case that isn’t clear, all relevant informational video in Ontario forever would have to provide four simultaneous alternate formats – captioning and a transcript and a sign-language interpretation, plus audio description.
What about video with no soundtrack, like in elevators or on the advertising screens in subway stations or at off-track-betting locations? There’s nothing to caption or transcribe. Where does the audio description go?
Why do we need a transcript if we also have captioning? Where is this transcript supposed to go?
How does one “transcribe” the “visual... information” in a video? This seems to be a reiteration – another one – of the failed fantasy scenario of deaf-blind people’s using a text transcript to understand a video. (I’ve covered this at length.) How are they going to do that while standing at a kiosk or on a subway platform? Where is the research showing that this is the preferred method of accessibility for that group or any group? (There isn’t any.) Where are the researched and tested techniques for writing such transcripts? (They don’t exist.)
Why are we providing sign-language interpretation when only 13,500 people in Ontario use any sign language? Where is the evidence that these people cannot understand captioning? If that is true, why is there so much captioning on TV, in home video, and at the movies?
Where are the video images of these sign-language interpreters or performers supposed to go?
Has the committee thought this through for even five minutes?
Or actually, every “spoken or audio recording” that provides “prepared information” has to be accompanied by “[a] structured text transcription or caption of the speech and audio.” This is the only section of the spec where “structured text” is permissible. What is it? “Text that contains markup to denote structural elements such as paragraphs, headers, subheaders, sections, pages and highlighted elements.” That would seem to comprise any kind of HTML (even mangled, invalid HTML – the only kind that committee members’ organizations are capable of producing). It also includes tagged PDF, whether the committee realizes it or not. (Tagged PDF may be the only internationally-recognized format that comprises everything on that list.) Some word-processing documents might qualify. This whole section is a mess.
Well, in practice they do. “Live text message[s]” must come with a spoken version. So much for the LED news crawler in your stockbroker’s office: Something or someone is going to have to read that out loud all day.
All “gestures and drawing” in videoconferences must have a “spoken description” and also real-time captioning.
Yes. It’s that simple. You don’t even have the option of meeting WCAG 1 (still in effect and never cancelled), let alone WCAG 1 plus the WCAG Samurai Errata.
Web applications have to use WAI-ARIA. While this is not bad, it makes Google Maps illegal right away.
The spec states the following plain as day: “User interfaces of existing IT-based systems shall be accessible.” Some things just aren’t accessible. For example, vision is a bfoq for the use of Photoshop (full arm motion isn’t), but as there is no provision for bfoqs, the use of Photoshop in an “existing IT-based system” would be prohibited because it is inaccessible. That would be true even if your organization employed no disabled people and never had disabled guests come to visit.
By the way, if you provide any kind of software application, it has to be accessible. It’s not clear whether this relates to providing software to developers or to the public: “When prepared information and communication is provided through a software application, the organization must provide an accessible software application.” Apart from being repetitive, what does that mean?
If you have some kind of computer application you are planning to roll out, you will have up to three years to make it accessible – except that you have to make the user interface accessible immediately upon launch. This latter requirement vitiates the former.
The committee seems to mix up relay services and interactive-voice-response systems. Nonetheless, if you have a system that callers talk to, you have to provide seven simultaneous alternatives (copy-errors in original):
- a. the ability to communicate or respond using an accessible dynamic Web site,
- b. the ability to receive live human assistance (e.g., to zero out for an operator),
- c. the ability to communicate through an intervener, personal communication assistant or sign interpreter provided by the individual,
- d. the ability to extend the time given to respond or eliminate “time out” completely,
- e. the ability to cancel or undo the last selection using an alternative to speech,
- f. the ability to respond in writing or text, and
- g. the ability to use the keypad instead of IVR system (interactive voice response)
In case you don’t understand that, your phone lines also have to work via some kind of Web interface. Your phone system has to somehow know how to read. Your automated system, put in place to reduce your staffing costs, always has to have staff available.
The business about interpreters or interveners is pointless, since, on an interactive system, nobody knows you’re a dog, let alone an interpreter or intervener. How is it even theoretically possible for this kind of system to prevent you from using it with that kind of help?
In any system, apparently including a Web site, that “expect[s] a set of choices to be made through typing,” you have to accept nine simultaneous alternatives, one of which is “the ability to respond using speech or voice recognition.”
What they seem to want to say is: If you have a system where people have to type, then they must also be able to talk to it and have it understand everything perfectly. This is flatly impossible, of course, and I emphasize again that it applies to your Web site too.
...because you have to provide:
- a) enlarged buttons or controls with increased spacing,
- b) guides, stabilizers and tactile labels to assist in activating buttons and controls,
- c) human assistance in activating mechanical controls, and
- d) direct access to all functions using a personally optimized assistive technology or personal mobile device.
That’s all four at once. Do you think your photo booth or transit vending machine could comply with that? At least you don’t have to produce a full auditory user interface.
Think things are better because you’re using membrane switches without “mechanical” features? Nope: You have to provide a second keypad with “enlarged controls with increased spacing,” “voice input” (there it is again!), a full auditory interface, and – incredibly – “mechanical keypad input alternative.” But if you provide a mechanical interface, don’t you have to also provide four alternatives for that? (One of them is the same in both cases – “enlarged buttons or controls with increased spacing.” That in itself is so impracticable as to be impossible, i.e., it constitutes undue hardship.)
...because, among other things, you have to provide real-time captioning of everything that is said. “Hi, may I take your order?” will never be the same. Oh, and if your nail salon or grocery store is large enough, it has to have an assistive listening device, i.e., special amplification for wireless hearing aids.
For “prearranged appointments that have significant personal impact for an individual” (like doctors’ appointments, I guess), you have to “provide a personal communication assistant, intervener, note-taker, and/or ASL/LSQ interpretation services.” That means you might have to provide all four of those services every time.
Organizations shall provide to persons with disabilities upon request their emergency and public safety information in accordance with Section 5 and Schedule 1 requirements. Information about emergency and public safety shall at a minimum include... evacuation procedures and information about facility alarms
The Ontario Building Code was updated in 2006 and 2007 and did not require, for example, visible as well as audible warning systems. Essentially, through the AODA spec, one arm of government seeks to require what another arm of government refused to require.
There’s another interpretation. “[I]nformation about facility alarms” could simply be as follows: “The alarms are audio-only and we have no way of making them accessible to you or any other deaf person.” There. That was your information.
If the intent is to force buildings across the province to retrofit their alarm systems so that deaf people and blind people can understand them, this needs to be openly addressed. Expect a lawsuit just on this topic.
Copy-editing remains appalling. This document was clearly written by a committee of non-writers who are afraid of their Windows 98 computer systems and don’t know how to produce a coherent sentence.
“information” means data, facts, knowledge and the subject matter that may exist in any format such as text, numerical, image or sound and that conveys meaning;
“Numerical” is a “format”?
...if any. Some situations aren’t urgent.meeting the needs of persons with disabilities in a timely fashion that recognizes the urgency of the situation
Some terms, like “business enterprise systems,” are defined over and over.
For some reason, the spec wades into electoral politics and requires parties running for provincial office to hold all-candidates meetings. By any rational reading, that means every party in every riding has to hold its own meeting. This has nothing to do with accessibility. A provision requiring that all-candidates meetings, if held, must be accessible would be a different proposition.
I still have several pages of the original specification marked up, but, 4,800 words later, I don’t feel like putting in any more effort. After all, the committee already showed it does not want my help.
Posted: 2008.09.12
You were here: Homepage → Accessibility; → CRTC filings and other interventions → AODA specification → The Ontario accessibility spec, Fall 2008 edition