Edbrowse and accessibility on the Web

One approach at making the Web accessible to people with vision impairments is to introduce support for screen readers, Braille displays and keyboard shortcuts into pre-existing Web user agents, of which the overwhelming majority, especially by adoption estimates, is designed from the start to employ point-and-click interfaces.

An alternative, which we find mostly overlooked, is to develop such agents, and indeed software useful for day-to-day tasks in general, around user interfaces that are convenient for a person with vision impairments to operate, from the beginning.

While the latter approach has its disadvantages, which we note below, it allows for several simplifications as well:

• it becomes no longer necessary to ensure that accessibility features play well along with the application’s primary visual interface, for the lack of the latter;
• in the case of Web user agents, no complex layout engine needs to be developed or maintained.

It can be argued that the lack of complex layout engine, and the higher demands on the computer hardware it imposes, would also be beneficial to the end user, who oftentimes would be unable to compete for higher-paid jobs due to the impairments.

The drawbacks, in our opinion, stem largerly from the fact that Web resources in general are developed with only major Web user agents in mind, which thus become the de facto standard that needs to be reimplemented (and, sometimes, reverse-engineered.) Moreover, the ever-changing nature of said standard requires constant maintenance effort from the developers of the alternative software, resulting in duplication of effort between maintenance of mainstream and alternative user agents.

Edbrowse provides an example of a mature Web user agent developed along the ideas outlined above. Its highlights include:

• command-line interface, modelled after the traditional Ed editor;
• Javascript support, via Duktape engine;
• integrated email (SMTP, IMAP, POP3) and database (ODBC) clients;
• fully functional as an editor proper.

Nevertheless, and as was already mentioned, support for modern Web technology, and first and foremost for the latest advances in Javascript, is largerly a moving target, and likely requires more effort than the current team of developers can provide. As such, and given importance we see in its aims, we believe that Edbrowse should be considered for inclusion in the forthcoming revision of the list of high priority free software projects.

Lastly, we feel appropriate to include below several guidelines to consider when developing Web resources and terminal-based software accessible to users with vision impairments.

• Do not rely solely on color, extended non-alphanumeric characters, or layout for presentation: relay the same information with words as well, or at least provide the user with an option to do so.

  For example, a speech synthesizer or Braille display are unlikely adequately reproduce green-on-white U+2713 check mark; but they will render ‘OK’ or ‘PASSED’ with no issue.

  Similarly, note that a speech synthesizer generally will not give indication to the user of how things line up on a character display. At the very least, when a table is rendered, columns should be separated by some character, such as a vertical bar, |.

• For terminal applications, avoid hardcoding control (escape) sequences and consult the Terminfo database instead: accessibility software and hardware may become confused by “standard” sequences to change colors and the like.

• Try to follow the semantic structure advised by the HTML Living Standard when designing a template for a Web application. Make use of the sheer repertoire of distinct elements available. Do not rely on CSS alone; in particular, use the pre element for preformatted text, not a div with a custom class attribute.

  That said, try not to rely on ARIA attributes, either, as supporting them requires additional effort which the developers of alternative Web user agents may be unable to provide.

  Try to put the payload portion of the HTML document as close to its beginning as possible (note that navigation items can generally be placed later in the code and “moved up” on screen by CSS.) Otherwise, at least provide a ‘skip to content’ link.

• Do not assume that any Web user agent, or even all the important ones, will support the latest additions to Javascript. Better still, ensure that most, if not all, of the material on the site can be read with no Javascript executed at all.

• It has become common to require some form of Captcha challenge to allow access to the site to prevent abuse. Given that such tests are not always accessible, and that they may require Javascript support beyond the capabilities of alternative Web user agents, try to ensure that such tests are only activated for the functions that are either likely to be abused, or otherwise likely to require higher resource usage on the server.

  In particular, for wiki sites, typically only login and edit functions need to be put behind such barriers; while reading the pages should be unrestricted.