Is A Protocol The Best Solution to Web-Content Accessibility?

Graphic image of visual eye test and reading glasses

If you have been around the internet since the mid 1990’s you may have the same sense of I have. The internet was better then. Gillian Anderson… and other reasons. Mostly the web wasn’t so… bull-shitty. There were less advertisements. There were fewer user interface changes to websites so you didn’t have to search for the button that some psychometric web-design team lead decided to move because you would look at ads longer if they made it harder to find. The real content still changed. Websites still changed and were updated. It was just mostly the content that changed not the UI.

I suspect that nobody has felt the wave of the new “bull-shitty” internet more than people with disabilities. Yes, accessibility features existed in the 1990’s for computers. They may have been even better than the state they are in today. Perhaps as Bill Hicks might say, it’s that “advertising dollar” that’s killing web accessibility.

Accessibility And The Web

People with disabilities make up around 13% of our population and is expected to grow over the next decade as more people enter the 65-80 age demographic. This means an increasing number of disabled people will be using the internet and relying on it. There are multiple standards that outline best-practices for web-content accessibility such as the Web-Content Accessibility Guildelines (WCAG) and Section 508 Government Wide IT Accessibility Program.

I have written another blog post describing new laws in Ontario, Canada and how to make your website compliant with the WCAG 2.0 “AA” standard. Visit this link if you want to know more about the WCAG standard and common issues that websites face in the compliance process.

However, in this post I want to think about the many problems you can face by simply trying to retro-fit your existing website content to the WCAG, and instead propose another strategy all together: An accessibility protocol for visually impaired users.

Accessibility Creates Site-Design Tradeoffs

For visually impaired people, web-content is navigated using a screen-reader that will parse the page contents and read them to the user with a text-to-speech software module. If you are familiar with the modern web, and it’s full of junk like advertisements, pop-ups, navigation menus, side-bars, widgets, and dynamic content such as image slider carousels. If it can be annoying to a person without a visual-disability, some sites are obviously impossible for people for people with.

Because visual-impaired and non-visually-impaired are both essentially using the same source code to consume a web-page, the source code must be over-layed with some syntax that indicates to a screen-reader. This makes designing or retro-fitting a website for accessibility a more complex process and thus conforming to accessibility best-practices has two negative effects that force tradeoffs.

  1. It increases the costs and development time of a site, which means implantation of accessibility features will be an afterthought with low-quality implementation if it is implemented at all.
  2. The site developer will have to choose between accessibility and site layout. This means that creative expression of the website by increasing its accessibility.

The current process of making a website accessible is mostly an integration of HTML attributes such as Accessible Rich Internet Applications (ARIA) attributes into the existing page’s HTML. You can read more about ARIA attributes here. While this process has made it possible for screen-readers to navigate, it is far from user-friendly.

For example, it may be nice to include a navigation menu in multiple places on your website, but when someone with a visual impairment is using the keyboard and screen-reader to navigate your site, their trajectory through the page content will be disrupted multiple times. Some fundamental web-content elements such as an image slider will also create this same disruption. Implementing an image slider is difficult enough for a native web-developer let alone with the added task of including accessibility friendly HTML attributes.

The Solution Is A New Protocol

The web is a circus of computer languages, protocols and encoding. HTML, CSS and JavaScript make up the big 3 and create a basic UI with dynamic content and styling. However, robots.txt a protocol for web-crawlers to respect a sites scraping policy, sitemap.html files, don’t forget about XML and JSON, UTF-8, HTML-entities, favicons, open-graph, base64, SCSS, web-assembly, SSL/TLS, HSTS, …. the list goes on. The point is that the web is already a complex ecosystem with layers of abstraction. It’s time for a layer of abstraction that separates visual- accessibility from the web-page DOM.

Each web-page could include a link to a file in the header and if a browser has visual impairment set as the user’s disability, browser plugins such A Google’s GoogleVOX or NVDA could load that file instead.

Here is what the accessibility.html file could contain.

Leave a comment

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.