Implementing Accessibility Presented by Adrian Roselli (@aardrian) for Accessibility Toronto. Slides from this talk will be available eventually and I may even tweet a URL. “Toronto Skyline” by Ronan Jouve, CC BY-NC 2.0

Within an Organization

Identify Stakeholders Reactive Approach: When a complaint comes in, how far up the chain does it go? Who is in that chain? Who is that person where it stops? Who is that person’s boss? I am certain there is a Buffy reference to made here somewhere.

Identify Stakeholders Proactive Approach: Give someone the authority to implement an accessibility strategy. Make sure that person has the backing of the top tier of the organization. Give that person the resources necessary to be successful. Create a cross-organization team. Or is this more of a Blade crowd?

Culture of Accessibility Build accessibility guidance into all support materials. Include accessibility in job descriptions and recruiting efforts. Include accessibility as part of performance review process. Establish community partnerships, including visible public support. Most cultures have holidays, so maybe ask for some days off too.

Training Identify teams or departments to receive training. Find a trainer (see Vendor slides). Create an ongoing training cycle to maintain skills and keep current. Find champions internally who can perform ongoing training. Cue We Are the Champions.

Build into Projects Integrate accessibility into each step of your process… Interface design, Prototyping, Coding, QA, Support, Etc. Treat accessibility issues as bugs. But the kinds of bugs you actually address, not those wont-fix you just ignore.

Budgeting Myth: “It costs twice as much to make something accessible.” Fact: Nope. For a new team it may be analagous to picking up a new coding standard / practice. Once integrated, just part of your process. Pattern libraries are an example of cost saving re-use.

With a Vendor

Be Wary of VPATs Voluntary Product Accessibility Template for conformance to Section 508. Insert any Canadian equivalent here (AODA? CDA?). Since they are voluntary, there may be no third-party confirmation of any claims. Generally not updated when a product is updated, including every release. Ask how validation and ongoing conformance is performed. VPAT could also mean Very Packaged Alternate Truth, via Joe O’Connor.

Tool / Vendor Evaluation Look for an accessibility policy. Look at tickets or pull requests. Look for accessibility references on social media platforms. Look at community engagement. Ask around. Ask for demos. Ask for posts / articles. Much of this assumes that the vendor or tool makes at least a passing commitment to accessibility.

Build It into Contracts Make your compliance requirements a line item in any agreements. Build testing into the agreement. Require a guarantee the vendor will fix any issues at no cost. Ask the vendor how it validates and maintains is compliance. Include an indemnification clause. Build time into your process since it may be a while before you hear back.

With a Client

Client Push-back Be prepared for clients to ask you to remove any accessibility “features” to keep costs down. Remind the client that you are the expert. If a client insists: Produce a letter explicitly stating that the client wishes to exclude accessibility features, Note the risk and your clear recommendation against, Include an indemnification clause, Require the client to sign it. If it is not obvious, clients who did not want to be accessible did not stay with me for long.

Implementing Accessibility Presented by Adrian Roselli (@aardrian) for Accessibility Toronto. Slides from this talk will be available eventually and I may even tweet a URL. “Toronto Skyline” by Ronan Jouve, CC BY-NC 2.0