IT Accessibility

IT Accessibility in the Last Decade: Progress, Gaps, and Strategy

With the new decade upon us, I thought it would be good to take a look at the evolution IT accessibility over the past one.

Needless to say, a LOT has happened. There have been many things that have resulted in improvements, but some lingering challenges as well.

The Technical Standards and Regulations Landscape

While the adoption of WCAG 2.0 by the W3C was slightly before the beginning of the last decade (2008), its application as THE standard for web accessibility really began to take hold a bit later. In the US, WCAG 2.0 AA was finally adopted by the US Access Board for use in the refresh of US Section 508 (by reference), effective in early in 2017. While a long time coming, anticipation of its adoption for use as part of this federal procurement regulation had prompted some of the larger COTs product  manufacturers and a few development services vendors to begin looking at, and in some cases trying to implement to these standards…or at least reporting compliance levels of their own products against these standards.

The ITIC VPAT reporting templates also changed in support of the new standards, spawning similar but different reporting templates for use beyond US federal procurement.  One of the biggest improvements in the new templates, in my opinion, was the inclusion of the “Evaluation Methods Used” area of the manufacturer information block. That section completed (or not) greatly assists those who know how to read an accessibility conformance report (ACR) in ascertaining the credibility of the information that followed.

In Europe we saw the adoption of EN 301 549 which uses WCAG 2.1 as well as other criteria. The standard was adopted by The European Union (EU) Directive on the Accessibility of Websites and Mobile Applications.

In Ontario, Canada, the Accessibility for Ontarians with Disabilities Act (AODA) was adopted, which also contained regulations and standards for web accessibility, requiring all entities doing business in the province to make their websites accessible.

Other regulations for IT accessibility were also enacted around the world, but this blog post is not intended to be a comprehensive report on that. There are folks in the accessibility community who do track such things, so I will defer to their expertise on such matters.

Then, in mid-2019, came ISO 30071-1 another accessibility standard, but uniquely different from WCAG, US section 508, AODA and others. As stated in its abstract, ISO 30071- “… takes a holistic approach to the accessibility of information and communications technology (ICT) by combining guidance on implementing the accessibility of ICT systems (ICT accessibility) both at organizational and system development levels.” This is an extremely important distinction.

The Legal Landscape

In the past decade, the rise in IT accessibility complaints and lawsuits grew at a rapid pace, rising to a rate of 1 per hour as the decade ended.  The lawsuits ranged in significance. The Domino’s pizza inaccessible website case made it all the way to the US Supreme Court, who upheld the lower court rulings in favor of the plaintiff. (the case is still ongoing, bounced back to the lower court post SCOTUS decision) There were other important  rulings ranging from  victories by  plaintiffs on captioning in Higher Ed and on demand video entertainment, all the way to frivolous “drive by” lawsuits propagated by law firms that used web accessibility scan tool reports as a basis to file, with no actual person with a disability represented. Many of these have been dismissed).

The visibility of these accessibility lawsuits as well as numerous high visibility marketplace articles by legal folks and others raised awareness levels of the risks of inaccessible IT, bringing the issue into the mainstream. While some of the legal activity around this, such as the “drive bys” were likely more motivated by money than ethics, in totality, they have the industry sitting up and taking notice, which will hopefully result in more accessible IT, even if for no other reason than being a risk mitigator.

It should be noted, however, that not all court rulings have been in favor of the plaintiffs, depending on where these cases are heard, who hears them, and case specifics.  One reason for this, at least in the US, is the lack of codified IT accessibility standards under the American’s with Disabilities Act that the courts can point to as law.

While the DoJ has publicly taken the position that websites are places of public accommodation, reinforcing this position when intervening in many of the complaints, its efforts to develop and codify IT accessibility technical standards and governance regulations into the ADA have thus far failed.

The DoJ began exploring what and how to implement such standards and regulations beginning in 2010 with an Advanced Notice of Proposed Rulemaking (ANPRN). As part of this effort, responses to included questions were solicited from the public. Federal work groups were formed. Work progressed, and in 2016, a supplemental ANPRM was issued, with many more questions soliciting public response. Then in 2017, the SANPRM was place on the inactive list, effectively mothballing the DOJ efforts for IT Accessibility codification.

As it turns out, many legislators still have interest in federal accessibility standards to assist in litigation resolution, but to date, I am not aware of any bills or other activity that would indicate further effort.

The Technical Landscape

There has been significant progress in the technical arena regarding development, testing and training tools which now available for understanding and producing accessible IT.  The creation of HTML5 and WAI ARIA, when well implemented, have mitigated many of the technical shortcomings of legacy development tools where IT accessibility features had to be reverse engineered, or even worse, remediated into IT offerings. Automated tools have become more plentiful, (yes there is now a competitive market for these!) more robust, and cheaper. Assistive technologies have become smarter, but more importantly, they are better integrated into mobile and desktop operating systems by the offering manufacturers, helping bring these end user tools to the people that need them at no additional cost.

Legacy products, however, continue to pose challenges even with the best intent of their manufacturer’s desire to make such products more accessible. Original code bases, sometimes a decade older or more, are problematic and possibly requiring total rewrites of product code to make them fully accessible. This is something that most manufacturers are reticent to do given the potential costs, technical risks, and backward compatibility support.

IT accessibility training has become more mainstream both online and classroom based. Still missing however; is the integration of IT accessibility courses into the relevant higher ed curriculums. Hopefully this gap will close as IT accessibility continues to increase its footprint. Additionally, we now have the International Association of Accessibility Professionals (IAAP), a body that provides certification in various areas of IT accessibility, as well as hosting webinars on a range of IT accessibility topics for its members and others.  

The Policy and Governance Landscape

This area continues to be lacking across public and private sectors.

First, in private sector, with the exception of some of the larger publicly held corporations, the majority of companies around the world still lack any sort of cohesive IT accessibility policy. This continues to be a concern, as without an appropriate organization wide internal policy on IT accessibility, the odds of progress being made to improve the accessibility state of the IT offerings within these is low.

In public sector, the problem is a bit different. Many entities across all of the geographies and at all levels of government do have policies on IT accessibility, but for some reason fail to either implement governance criteria around the policies, or just escape its use, even when IT accessibility is mandated in standards and regulations. The result is failures in critical areas such as IT procurement and development which impact both the public, and the internal workforce.

It should be noted that such policy and governance gaps today can less attributed to technical and cost obstacles of decades past, but rather manifest due to organizational leadership and culture deficiencies. As a few examples:

  • Lack of commitment by organizational leadership
  • Lack of knowledge and awareness (yep. Even though IT accessibility had been pretty visible since before Y2K)
  • Lack of Motivation – Don’t see the value, so why invest?
  • Lack of integration into relevant processes organization wide
  • Fear of financial or product competitiveness risks
  • Lack of understanding of repercussions if IT accessibility issues arise

Sound familiar? But how can such inhibitors be addressed?

Announcing the 2nd Edition of Strategic IT Accessibility: Enabling the Organization – available in early February!

Book cover for 2nd  Edition of Strategic IT Accessibility: Enabling the Organization.
2nd Edition Book Cover

Some of you have read and used the original edition of my book. I received lots of kudos and positive feedback from people who used it to help implement IT accessibility programs around the world. Thank you all for the kind words, and I am delighted that the book was so useful.

But, as this blog post suggests, a there has been a lot change and progress in the area of IT accessibility over the past decade. This includes evolved thinking and experience. Therefore, I felt that a second edition was needed to encapsulate all of this for the benefit of the industry.

In this edition, I have added new information, tools, and approaches that can be used by folks at all levels of an organization…from C Suite to the test lab.  Its still the only book of its kind with both strategic and practical information. And, like the 1st edition, it’s based on actual private and public sector operational experience, not theory.

It also includes a case study from ING Netherlands, contributed by my friend and colleague, Jake Abma.

The book will be available in early February in both paperback and eBooks formats at (preferred) and well as other online booksellers. I will let you all know when it’s ready for purchase.  In the meantime, I suggest you hold off on buying the original 2011 edition, which is still in circulation. The new one will have a red diagonal band that says “2nd Edition.” (see the cover image at the beginning of this section.)  

Happy New Year! Let’s continue making the world a better place this decade, shall we?


Throwing Your Organization’s Money Away Or Why Must Your Organization Pay to Test Accessibility of IT Products and Services It Purchases??


Your organization has just purchased a new enterprise IT product. And your organization is one of the ones that takes IT accessibility seriously. Yay!

But taking it seriously by no means translates into spending large sums of money, time, and other resources to thoroughly test the accessibility of the product or service that you just procured, or are in the process of procuring.

Think about it. Some of you out there know I’m a car guy, and I love car analogies…no doubt a carryover from my days in the world of Industrial Design, where car analogies were often used to convince engineers or management why a product should be designed a certain way.  So, let me use one to make an important point about accessibility testing.

Let’s say that you are in the market for a new car. One of the important features that you would be interested in is safety, obviously.

You do your research…price, brand, performance, style, warranty, and then safety of course. You select the car you want that has the right blend of all these things. You look at the safety ratings / certifications, like what you read, so you buy it.

Now that you have acquired the vehicle, would you be expected to ensure the safety specs on the car are true and accurate? Airbag deployments, side impact reinforcement, crumple zones, etc.? How would you go about doing this? Drive your car into a tree at 60 mph?!?

Of course not. Fact is, the manufacturer has already performed extensive testing of the vehicle’s safety systems and has certified that the vehicle meets these standards, and to what degree.

Accessibility testing by who? And how much?

Hopefully by now, you have figured out where I’m going with this blog.

Is it reasonable for your vendors to expect you to perform comprehensive accessibility testing on their products and online services? You might think it is because:

  1. Tradition – That’s the way it’s always been done
  2. Confidence – You feel that it’s the only way to be sure that the product meets the accessibility criteria defined in the SOW, contract, or the policies for your organization.

OK, the tradition aspect is problematic on many levels, as a “tradition based” IT model is far from the modern IT models used in both private and public sectors.

Confidence in what you are procuring is certainly valid, but there are things that can be done in the procurement process that can effectively build that confidence thereby reducing the need and costs to your organization for IT accessibility testing.

First, let’s look at some of the issues around customer testing of procured offerings:

  1. Testing needs to be performed throughout a development process, starting at unit test, to identify and correct issues early. Customer testing would typically be performed far down stream in the development or post development process making such testing a very late way to identify issues and have them resolved. This is especially true for large, complex applications so the likelihood that fixes would be integrated into the version a customer buys is low. (“We’ll put it in the next release…”)
  2. IT accessibility testing typically requires a deep understanding of the product / service to be tested in order to develop test plans and execute those plans. This means knowledge transfer from the vendor to the customer, and assumes a willingness by the vendor to do so.
  3. Testing may require a specialized IT environment to install and test the IT asset that the customer has yet to deploy. In some cases, access to a vendor site where an instance of product / service is installed may be provided, and hopefully complies with security polices of the customer organization.
  4. And last but not least, there are the cost considerations (Human resources+ time+ test tools+ documentation) associated with proper testing either through the customer internal accessibility testing facilities or the use of a third party.

When these aspects are considered, its fairly obvious where responsibility for testing should reside. The question is, how do I as the customer make this happen?

Some guidance to consider for how to minimize customer accessibility testing of vendor supplied products / services:

For Commercial Off the Shelf (COTS) products and services:

  1. In the solicitation document, SOW, etc. include language that
    1. Specifies the accessibility technical standard to which a vendor’s products need to comply. (hopefully you are doing that already!)
    2. Incorporate the requirement for accurate VPATs for any COTS procurements. If the vendor cannot provide them, that can be a good indication that the product has never been tested and accessibility levels not documented. Therefore, it’s safe to assume that the product is not very accessible.

At that point, you can ask the vendor to provide a date when an accurate VPAT(s) will be available, so that at least you have a good understanding of the risk you are assuming.

  1. Analyze the VPAT. Accuracy varies wildly from vendor to vendor and product by product. After reviewing it, asking for additional information is key:
    1. Can the vendor provide a copy of the accessibility test plan for the product?
    2. What tools / methods were used to test and complete the VPAT? The response should include accessibility tools and methods with which a knowledgeable accessibility professional would be familiar with.
  • What client platforms (operating systems (including mobile), browsers, assistive technologies, and versions of all of those) were used as test environments?
  1. Can the vendor provide the results of the accessibility testing?
  2. What issues were found and are there corrective actions in place to resolve them in this or a subsequent release…and when?

If these questions can be answered to your satisfaction, and given that the responses to these questions plus the VPAT documentation serve as “official documents”, then your organization can likely forego the arduous task of comprehensive accessibility testing.

If the vendor is unwilling or unable to provide satisfactory answers, you should assume that the offering is not accessible and factor that into your decision-making process. Your testing at this point would be a waste of time and money.

There may be cases where vendors may not be able to share such information with you as it may be deemed confidential; however, you can always ask to sign a nondisclosure agreement (NDA) with the vendor to allow them to provide the needed info.

If still, the vendor cannot supply this information, you should request a letter of certification from them stating something to the effect of “the product was tested in accordance with generally accepted accessibility testing practices (including visual inspection and with an assistive technology) and that the information in the VPAT(s) is accurate.” Note: The letter should support the level of compliance as documented in the VPAT(s) and should not be written as a statement of “full compliance”, unless the product is in full compliance, of course.

If the vendor is unwilling to provide such a letter, and the VPAT looked sketchy to begin with, then again assume the product is not very accessible and base your business decisions on that. Certainly, don’t waste your time and money testing the damn thing!

In all fairness, I do not advocate total elimination of customer (or customer paid third party) testing. Depending on the asset being procured, the customer easily “sniff’ test in a few places to validate the accuracy of the vendor test documentation or their letter of certification, and to ensure there are no assistive technology interoperability issues within the customer’s solution platforms.

For non-COTS deliverables:

Non-COTS deliverables, for the purpose of this blog, can be defined as custom development services or customization of COTS offerings. The main distinction from COTS is that there are no VPATs or other accessibility documentation because the deliverables don’t yet exist. Therefore, what you really want to ascertain before entering into an agreement with a vendor for development services is whether the vendor has the knowledge, skills, tools, policies, processes, and track record to produce accessible deliverables. (examples websites, web applications, client application, or customized front ends for COTS products, etc.).

Some of the elements described above for COTS offerings will be the same for non-COTS, but there are differences in that as the customer for development services, you have much more control of what you can require of the development services vendor.

  1. For the solicitation document, contract, or SOW, etc. here are some considerations:
    1. The accessibility technical standard that you want the deliverable to meet such as WCAG 2.0 AA (included again for completeness);
    2. Your review / approval of accessibility plans / designs at designated checkpoints throughout the development cycle;
    3. Your review / approval of accessibility test plans and tools / platforms used for testing
    4. Delivery of accessibility test results documentation;
    5. Development process corrective actions criteria (prioritization of issues, and resolution plans / dates);
    6. Accessibility related remedies and warranties; and
    7. Statement that you may request additional information as needed in support of the vendor response to the solicitation documents

Additionally, you can (and should) include accessibility specific forms for the vendor to complete that will help you gauge confidence in its ability to produce quality, accessible deliverables. Note that these completed forms should be evaluated by a knowledgeable accessibility professional.

At the Texas Department of Information Resources, we developed one such form, The Vendor Accessibility Development Services Information Request. Vendors must complete this form as part of any solicitation where development services are being procured. It asks for qualitative information regarding a vendor’s accessibility policies, organization, tools, training, corrective actions, and examples of prior accessible work. The completed form can be a significant indicator as to a vendor’s accessibility development capabilities; and can be used to gauge the level of confidence in the vendors testing and results, should that vendor be selected.

You may already be familiar with Policy Driven Adoption for Accessibility (PDAA). It is a system developed by myself and my counterparts in Minnesota (Jay Wyant) and Massachusetts (Sarah Bourne) through the National Association of State CIOs (NASCIO). To read more about it go to to download the 2-part whitepaper authored by Meredith Ward (NASCIO), Jay, Sarah, and myself. PDAA includes a tool that can be given to vendors that measures the level of accessibility maturity within an overall organization. The completed form maps responses to the PDAA maturity model, which can then be used as part of the vendor selection criteria.

Please bear in mind that it’s perfectly acceptable to ask for more detailed information about the responses you receive in these forms, as vendors should be able to substantiate them.

One thing I also like to do is visit vendor websites and run the WAVE tool against their home pages to see if they are eating their own dog food.  I have to say that the results are not always impressive, and can be another indicator of a vendor’s culture and commitment to accessibility.

  1. Prior to final delivery or go-live, the vendor should provide a letter stating that accessibility development and testing was performed in accordance with generally accepted accessibility practices (including visual inspection and with an assistive technology) and that the test results and other documentation supplied to your organization are accurate, and that the deliverable complies with the specified accessibility standards (or cites exceptions where it doesn’t with a corrective actions plan) set forth in the contract or SOW.

To state the obvious, this letter may not only be provided as part of fulfilment of the contract, it can help insulate your organization from liability should issues arise.

Again, I do not advocate total elimination of customer testing (or customer paid third party), but if the vendor’s test results are comprehensive and accurate, which can be assumed given all of the other checks and balances I’ve described, some customer “sniff” testing may still be performed for the same reasons mentioned in the COTS section.

Third party testing

One final point: My colleagues in the third-party testing business may have some concerns regarding the reduced need for customer testing, but I would argue that transferring this obligation to the vendor community creates new opportunities for third party testing on the other of the equation.









Policy Driven Adoption for Accessibility (PDAA)

The development of an easy to use IT Accessibility governance model for gauging the level of IT accessibility maturity within any organization, developed with and through The National Association of State CIOs (NASCIO).

To view or download the PDAA white papers, go to



Originally posted in 2013. Happy reading!



I recently returned from DEEP 2012, a conference on ICT accessibility organized by G3ict and sponsored by the Ontario College of Art and Design (OCAD) University. The conference was held in Toronto and brought together thought leaders and experts in areas of ICT accessibility, covering an array of topics and brainstorming sessions related to moving ICT accessibility forward at a greater clip.

Although not on the agenda, one topic pervasive in both the formal and informal conference discussions was related to the frustration around the lack of solid ICT accessibility business cases.


The Accessibility for Ontarians with Disabilities Act (AODA) took center stage on day one with representatives involved in shepherding and implementing provisions of the Act speaking on various aspects of it.  AODA is applicable not only to Ontario’s government bodies, but to private sector organizations as well (effective in 2016).
  How well AODA works to increase ICT accessibility adoption remains to be seen as the implementation of many of the important provisions has just begun, and there will no doubt be a few bumps along the way.  But the fact is, Ontario has done what no one else has done to date: require entities in both the public and private sector doing business in the province to make their ICT (web specifically) accessible through a governance model that includes a requirement for organizations to report specific criteria through an online filing system operated by the province.


How was Ontario able to adopt such a law?  Do you think there was a business case that supported it?  If there was, it would have certainly been externalized by now, right?  AODA didn’t need a dollars and cents kind of business case for ensuring equality to all of Ontario’s citizens, including people with disabilities, because it views accessibility as a civil right.

For what I consider an “apples to apples” comparison, let’s look at accessibility regulations for the built environment…choose a state, province, country, etc.  Were there business cases that justified the cost of fitting new and existing buildings for accessibility?  While there  were probably numerous impact assessments done, I’m not aware of any use of business cases, because business case justification is not relevant when dealing with civil rights issues.

If you follow this rationale, and the precedent set for accessibility of the built environment, why is business case justification a valid argument for providing access to ICT? What’s different about giving people physical access as opposed to ICT access?  Civil rights wise I would argue…nothing.

Before accessibility regulations for the built environment were enacted, entities rarely would have decided to expend financial resources of their own volition for accessibility because physical accessibility was an expense that they would have rather not incurred and didn’t see the need to incur it. So if left up to the entities themselves to “do the right thing”, very little would have been done, leaving those with disabilities literally out in the cold.  To solve this problem, regulations were enacted. While enforcement was and can still be challenging as new situations arise, the initiative has been very successful given the scale of the built environment. In the US for example, you will rarely encounter a commercial building code that doesn’t require full compliance to accessibility laws. Also, oversight and enforcement is fairly strict.


Now, let’s turn to the ICT environment.  What motivation, other than “doing the right thing” do organizations have for investing (yes, it does require investment) in ICT accessibility?  Let’s be honest here.  When comparing the ratio of the number of organizations that develop, sell, or use ICT worldwide to the demonstrated business case and ROI examples for increased revenue and profitability from implementing ICT accessibility over the past 10 years, the ratio is pretty darn low.

The same holds true on the litigation side. Sure, there have been a few high visibility cases, (mostly settled and not ruled on by judge or jury) but again, not many in relationship to the number of organizations in the global ICT environment.

When private sector organizations looks pragmatically at such data points, the business case for investment in ICT accessibility adoption doesn’t look all that compelling, leaving little in the way of incentive to take ICT accessibility seriously.

So, if the ROI case isn’t clear, and the risk of inaccessible ICT is low, how can organizations be convinced that ICT is important and needs to be adopted?


Equal access to goods and services, be it physical or electronic, is not a business option, it’s a civil right.  Therefore, we must look to government to ensure equality for all citizens at all levels of ability by enacting better regulations to guarantee all individuals access to ICT based goods and services…just like the built environment.

“But there already are regulations”, you say.  While this is true, most current disability regulations (not to be confused with technical standards) with respect to ICT accessibility governance are not well defined and therefore not very enforceable.

One element missing in many accessibility regulations is a simple, yet fundamental element that could significantly increase adoption: Include provisions in ICT disability regulations requiring organizations to have and implement an ICT accessibility policy.


It might look something like AODA, with respect to requiring organizations in the public and private sectors to have a web accessibility policy and report accessibility criteria through a government operated database.

The state of Texas has rule provisions that apply to all state agencies and institution of higher education requiring them to have an ICT accessibility policy; however, the provisions do not encompass other governmental bodies or private sector organizations in the state, nor does it retain a database of agency compliance to ICT accessibility criteria.

The idea behind integrating ICT accessibility policy mandate into disability regulations and requiring the filing of those policies with a government body is to compel organizations to drive themselves towards higher ICT accessibility adoption through compliance to their own “official” (filed) accessibility policy (I call this Policy Driven Adoption).  The policy provisions would have to contain criteria as to what would be required in organizations’ ICT accessibility policies which, by the way, would be filed with the government authority responsible for accessibility regulations.

Requiring a filed policy shouldn’t be too difficult to enforce/audit, as the high level action of filing criteria may be fairly binary…an organization’s policy is filed or it isn’t. It contains the correct criteria (setting achievable deadlines, and requiring organizations to show progress in their initiative, for example), or it doesn’t.  Audit-ability of how well an organization’s ICT complies with their own policy gets a bit more challenging, which is where ICT accessibility technical standards might then come into play, but perhaps just reserved for situations when an actual complaint is filed and investigated. (similar to how complaints are handled dealing with the built environment)


I would also predict that Policy Driven Adoption would encourage innovation in ICT.  As an example, look at automotive mileage standards which are essentially policy driven. While the automotive industry was initially opposed to stricter standards, they have now fully embraced them, which has given rise to countless innovations in automotive technology, promoting healthy competition, and resulting in a better, cleaner environment that benefits everyone.

The same could hold true for ICT innovation due to the increased demand/requirement for  accessibility…invention of new developer tools to automate and facilitate the development of accessible ICT and accessibility technologies, leveraging of cloud resources to enable accessibility at the end user level (SIRI as an example), or creating other things that we can’t yet even imagine, much of which could benefit everyone.

If a Policy Driven Adoption approach takes hold and begins to be embraced by industry and innovators, the benefits (and business cases) will emerge.

To make this happen, efforts need to be focused on getting policy requirements for organizations into regulation, which isn’t a trivial task, but a highly necessary one.