EasyDNS’s accessibility policy documents place the company well ahead of the minimum requirements of the AODA Customer Service Standard. But some implementation details need adjustment.
The purpose of accessibility in this context is to provide equivalent access to products and services. (Equivalent does not mean equal for the simple reason that treating persons with disabilities “equally” is what results in discrimination or unequal access.) When accessibility is required and offered, it levels the playing field and all but nullifies the effect of disability.
As such, naming an accessibility policy Enhanced Assistance suggests something other than equivalence or a zero-sum outcome. Where accessibility deals with alternative methods to achieve the same result, “enhanced” access implicitly puts the customer with a disability ahead of everyone else. By implication, Enhanced Assistance leaves a disabled customer with an advantage.
That clearly is not the intent of the policy or of the actions EasyDNS has taken and intends to take. It would be prudent not to rename or brand the basic concept of accessibility or accessible customer service.
The document entitled “Policy regarding access to services and respect for the dignity of easyDNS users with disabilities” states:
As enhanced assistance places an additional load on both our systems and support staff, however, we must regretfully reserve the right to request [proof of disability] if there is evidence that false requests are being made.
There seems to be some kinship here between the statement and the ability of, say, a human-rights tribunal to dismiss a vexatious or malicious complaint. In practice, however, there will be so few spurious or “false” requests for accessibility that they can be handled on their own terms if and when they happen. Inclusion of a statement like the foregoing undercuts the message of the rest of the policy and may become the only thing customers remember about it. It will tend to elicit alarm or resistance among customers. It may, moreover, discourage customers with less-common disabilities (e.g., a hearing person with a speech impairment) from requesting assistance because they fear the rarity of their disability makes it seem less credible.
In short, design for the majority case. Exceptions should be handled as such.
EasyDNS’s policy should not speak of acting as the hands or eyes (or ears) of a customer with a disability. That kind of metaphor is applicable in real-world environments (like shopping in a grocery store). But the fact is that EasyDNS relies on a technical infrastructure than can be intrinsically accessible (its Web site) and another that can be accessible with adaptive technology or outside help (phone lines). All those accessibility features, when put together, erase the disability and remove the need for EasyDNS staff to act on customers’ behalf.
A blind person using an accessible Web site just becomes a user of the Web site.
A deaf person using the telephone support line via TTY or the relay service just becomes somebody on the other end of the phone line.
In general, a company should never argue that service for disabled customers can be provided by only one method when nondisabled customers have more than one method. As an example, customers with disabilities should not be promised service equivalent to what they would find on the Web site but they have to use the telephone to get it. Nondisabled customers can go online or use the phone. An accessible Web site and an accessible phoneline provide the same option.
There is an unintentional message of disempowerment in these clauses. On the one hand, EasyDNS may deem your request for accessibility to be “false.” On the other, it will enhance its assistance, taking over for you and acting as your defective body parts. These tend to be at odds with the equalization and normalization functions of accessibility – of putting everyone on the same functional level – and need to be reconsidered.
Reading and writing E-mail is not an insurmountable task for any disability group.
Blind people certainly have no trouble reading and composing electronic mail. In fact, blind computer users have been doing so since easily the 1980s. Even HTML E-mail is not really a problem for this group (assuming alternate text is included on images).
A person with a reading disorder like dyslexia would not find E-mail more troubling than other forms of text. They would use the same strategies and assistive technology for E-mail that they do with everything else, including speech output and voice dictation. (Otherwise how do they use their computers?)
Save for unlabelled images, at root E-mail is not inaccessible. There is no accessible alternative to E-mail, nor does one need to be developed.
The idea of a designated secondary contact is reasonable on its face, but it might not end up being used the way EasyDNS has imagined.
Let’s set aside for the moment the case of a legally incompetent person (e.g., with a long-term brain injury) whose affairs are being managed by a person with power of attorney. That’s a different category altogether. So is the category of an under-age customer (a minor) whose parent or guardian talks to EasyDNS.
The more likely users of this service are persons with severe physical disabilities (like some quadriplegics) who find it taxing to talk on the phone for long periods, and some very-high-end professional deaf people who make a lot of phone calls through interpreters.
In the latter case no special designation is necessary, because interpreters are functionally invisible (and will change from day to day). It is the former case that will come up more often. There, personal-care attendants might call in on the customer’s behalf. It may be impractical to pre-register these attendants’ names because customers in this category can use several attendants just in the run of a day, let alone a week.
It may be more expedient to simply handle an interpreted call like any other call with no special fanfare. For severe physical disabilities, pre-selecting an option during the sign-up phase stating that an attendant might make a call on their behalf would probably suffice. (Obviously EasyDNS staff could tick that box themselves when a customer calls in the first time using an attendant.) Pre-registration by name seems excessive. Names will change.
There is another category that may be relevant here, and it is one already mentioned. A person with a speech impairment who still can hear (think Roger Ebert) might use the phone by having someone else read out typed or written messages while just listening to whatever is spoken in response. (The so-called hearing-carryover or HCO function of relay services enables exactly that sort of thing, but seemingly few people use it.) It again seems like a bit too much of an institutional formality to pre-register those respeakers.
The policy could be improved somewhat by more plainly stating how a customer can self-identify as needing accessibility. Phoning in via the relay service is an obvious indicator right up front, but it may be preferable for the policy to state in easy terms that a customer can tick a box on the Web site requesting TTY-only service or similar accommodation.
A document states that “[p]lans are also underway to create an automated system which will send a voice update in the event of urgent information updates.” (Presumably that means an automated system places a voice telephone call.) The sentence needs a rewrite, but in any event the issues are:
CRTC ADAD rules will apply.
Some customers won’t want to be telephoned under any circumstances.
Some customers won’t be able to hear an update delivered via voice phone.
The documents intelligently discuss TTY/TDD calls handled through the relay service. EasyDNS’s experience is apparent here, especially in the warning that a relay call can take an hour or more. At some point it just becomes cheaper to set up a dedicated phoneline for TTY calls only.
You might not need to install a new line; any direct-dial line could be reused for that purpose, but that would become its only purpose from that point onward.
You’d need a standalone TTY modem, of which apparently only one model (Ultratec Intele-Modem, $329), is currently manufactured. Apparently any kind of terminal-emulation software will work as a front end. Just a few hour-long relay calls would easily burn through $329 worth of marginal staff time.
With a direct TTY line, the rep’s TTY call would take place in a window on the same computer that actually troubleshoots the customer’s problem. (You could copy and paste between windows.) Everything would be done in text or in writing and, based on experience, would shave off up to half the elapsed time for a TTY call. (The TTY line could be a local number that always accepts collect calls.)
A less desirable option is to buy a standalone TTY (or an HCO/VCO TTY) and use that, but then you lose the advantage of locating the call and the means to resolve the call on the same device.
Any customer who calls in via the relay service could be asked to hang up and call the TTY line. There might still be a small residue of relay calls, particularly for customers using video relay service (VRS). Though available in Canada only for a short time as part of a pilot project, VRS ultimately will be made available everywhere in the country. Using video cameras, a deaf person uses sign language, which a qualified interpreter translates into voice and vice-versa. These callers would not be using a TTY in the first place (they’re signing with an onscreen interpreter) and would always call the voice line.
Over time, TTY calls will dwindle, because the young generation of deaf and hard-of-hearing people does everything by text message, E-mail, and chat (also videoconferencing); many young deaf people don’t have a home phone line, let alone a TTY.
In the not-too-distant future, the entire Web site needs to be upgraded to WCAG 2 AA level at the least. (For basic usability, reset buttons urgently need to be removed from all forms.)
iOS apps need to work well with VoiceOver.
EasyDNS is cautioned against doing the foregoing work in-house.
All customer-facing documentation has to be provided in something similar to valid HTML (ideally truly valid HTML). It would be tokenistic for only the accessibility-related documentation to achieve that code standard.
If and when PDFs are used, they have to be tagged PDFs, which OpenOffice can output automatically. As with all structured documents, use true heading styles (Heading 1 or H1, not bold plus bigger font) and correct semantics for all text (paragraph, list item, image with alternate text, etc.).
It would be preferable for all internal documentation to exist as reasonably or entirely valid HTML for ease of use by all staff. Keep in mind that EasyDNS, like all employers, cannot discriminate in hiring on the basis of disability; while unlikely, at some point in the future EasyDNS may hire an employee with a disability that necessitates accessible internal documentation. Plan ahead.
A disability is not a “challenge” or a “difficulty.”
The AODA applies to “organizations” in Ontario, not just “companies.”
“TRS” is an American acronym. (So is “MRS” for message relay service.) Canadian English generally just uses the phrase “relay service.”
The documents could use a rewrite for simplicity and readability and seriously need outside copy-editing, as by Moveable.
Even though it’s legally required, providing accessibility is a value-adding proposition for a company brand – especially in the technology field, where the halo effect of Apple’s built-in accessibility features has spread through the whole industry. At the very least EasyDNS’s work should lead to a series of blog posts.
Posted: 2012.07.17