We recently had a client for which we made a series of recommendations for their future website. As a public body they were obliged to conform at the very least to the W3C WAI WCAG (Web Content Accessibility Guidelines) Priority II compliance standard and we made specific recommendations around that area.

They tendered for the work and almost a year later their chosen supplier has nearly finished the implementation. But there’s a BIG PROBLEM. Their supplier has purchased an off-the-shelf menu widget from a third party to build some slick dropdown menus. While the third party promises Triple-A and 508 compliance, in practice it is anything but.

JavaScript Stew

The beautiful cascading menu is implemented in a messy stew of JavaScript and HTML tables. We tested it using the keyboard and on JAWS and it was a disaster. It couldn’t even be tabbed to and required a special accesskey to be activated (ALT Q). Even when activated, it couldn’t even be tabbed through, it had to be navigated using the arrow keys (not conventional behaviour for keyboard navigation).

As for JAWS, the menu was of the Kaiser Sozé variety. For all intents and purposes, it simply wasn’t there, it was like it didn’t exist.

The supplier’s approach was to put in (badly) an alternative HTML menu between <noscript> tags as they assumed JAWS didn’t support scripting. But infact, JAWS and JavaScript are not mutually exclusive.

Who is to blame?

Firstly, the supplier has been contracted to build a website that conforms to W3C WAI WCAG AA compliance. That is what they promised and that is what they need to do. The contract is between them and the client.

What to do about it

In future, if someone claims a level of compliance, make independent verification a part of the process to sign-off on any such claims and as for those who want to buy a AAA, Gold Medal winning, all-singing, all-dancing menu widget, test it first rather than relying on broken promises.