Nearly a year ago, we launched our Private Beta. Prior to that, we chose to do an important refactor to how tests were written that allowed tests to be more accurate. We launched Tenon this February with 66 tests. Today we pushed 21 test improvements, 16 of which are new tests. This is not as many as the 43 new tests that we’ve been discussing since launch. Why? There are a handful of reasons really, relating to higher priority features, resource constraints, and our testing philosophy.
Tenon takes an entirely different approach to testing compared to other tools. The most notable difference is that we don’t test for conformance; we test for accessible user experience. Our feeling is that conformance is an artifact of accessible user experience, not the other way around (To Hell with Compliance). Our tests aren’t written as a means to satisfy meeting a standard. They’re not aimed at testing against WCAG’s Sufficient Techniques and detecting defined WCAG Failures. There are of course numerous similarities, because WCAG is an excellent standard, but if we find a "Sufficient Technique" to be insufficient, we might choose to ignore WCAG.
One example of this is the example of nested tables. This bastion of pre-CSS layouts remains a practice in web-based COTS business software, particularly those featuring legacy code. Unfortunately, nested tables are a terrible practice. They’re bad coding practice, introduce maintenance headaches, and can be a problem for multiple disabled user populations.
The population with the most significant number and severity of challenges for nested layout tables are users who are blind. Nested tables can cause severe issues with reading order of content. They can also add unnecessary cognitive load as the user repeatedly hears each new table announced and tries to understand the content and structure of the page. For screen reader users, this latter challenge can be alleviated by adding role="presentation" on the table. By doing so, an ARIA-supporting assistive technology will ignore the table semantics entirely, allowing the screen reader user to hear the content without the extra cruft. The use of role="presentation" does nothing to fix any of the other possible issues relating to tables and also does absolutely nothing for users of assistive technologies that don’t support ARIA.
There are many questions we face with this sort of situation:
- Do we raise an issue for nested tables when the developer has made a conscious and (hopefully) well-informed decision to use role="presentation"?
- Do we allow role="presentation" to pass despite the other possible issues?
- Do we have two tests, each with different severities and messaging?
With today’s changes, we’ve chosen to only log an issue if the tables lack the ‘presentation’ role. We’re still contemplating whether to add a 2nd test with a lower severity. At Tenon, we focus on accuracy over completeness and user experience over compliance. We feel that just because something doesn’t match up to a defined WCAG Failure, if it causes issues with accessible user experience, we should surface that issue. The same goes for standards compliance. Just because
<i> are valid elements, their usage is likely to cause readability issues for users with dyslexia, even when used as intended by the HTML5 specification. We will definitely add a test that logs issues for
<u> very soon. It is also likely that we’ll do so for long passages of text marked with
We try to hard to provide effective, accurate, and actionable reports. The WCAG standard itself says "Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability." Tenon seeks – to the extent that it can – to provide testing that can cover all possible cases so our users can improve their sites and improve the accessible user experience. To do so, and to do it right, requires feedback from our users to ensure the information we’re providing is accurate, relevant, useful, and actionable. You should always feel free to contact us at email@example.com with your feedback.