Design decision 4 - Basic HTML mode and progressive enhancement



There is no clear explanation of what the basic HTML mode should do and/or should behave. The progressive enhancement design principle are not or can not be always followed when using some WET feature.

A clear definition is needed for WET 5 and to solve various issue/question about basic HTML mode.


Historically, the basic HTML mode was assumed to be the version equivalent of when the browser deactivate any javascript. WET4 currently apply that approach per his design because it would prevent WET feature to initiate. A funny fact is WET 4 rely on running some javascript code in order to be in Basic HTML mode.

WET 4 was kind of founded on the principle of progressive enhancement where author should create web pages that are in his basic form and then the web experience toolbox enhance the content into an interactive interface which have an high probability to meet WCAG 2.0 Level AA requirement. The documentation around WET feature do not clearly define what their basic HTML form should be. Even some WET feature became broken in the basic HTML mode.

Basic HTML mode was intended to provide a fall back when a user ran into issues with the “widget”. It was modeled on such sites as gmail. They still have this feature, even in the gmail web version that was released on spring 2018.


Conforming to the latest version of WCAG Level AA is the core driver for this project. WCAG 2.0 Level AA do not means to strictly following the progressive enhancement design and it do not require to check the conformity based on the principle that javascript are not executed.

Some browser vendor do not have an easy way to prevent the execution of javacript. Like in Edge it is not possible to deactivate javascript via updating it’s standard configuration GUI.

As per WCAG, the conformance check is evaluated only after the page are ready to be navigated and are in a state where the user can interact with.

The progressive enhancement design approach was used to ensure that WET feature would have a nice fall-back in the case the WET feature are broken. Usually that fall-back would provide a simpler and linear interface.

WET are designed and developed based on the capability of the supported browser.

Clarifying the interpretation of what means “Basic HTML” are going to support the design of the next major release of WET.

The basic HTML feature was primarily to address difficulty on the part of a user or incompatibility between AT+Accessibility API+Browser for a specific technique or coding practice. e.g. Dragon Naturally Speaking v12 and prior didn’t recognise any ARIA attributes on any browser. As May 2018 it’s not fully supported everywhere. With over 130 different pieces of software and 4000+ technical aids (AT) in use in the government of canada and many more outside, there are lots of possibilities for these problems.

Proposition of interpretation

“Basic HTML” is a simpler and linear interface of a WET feature. It require to have the page content going be initialized in a basic HTML form. It may use some javascript and its usage are going to be limited to execute simple low impact task as per design of the Basic HTML mode.

The expectation is that a user could select basic html and only be presented with HTML controls and whenever possible html markup without javascript interractions. This does not mean you didn’t get or use javascript. Just that you avoid complex interractions.

When a WET feature are initialized in its standard form or any other pre-enhanced state and the page is requested to be in basic HTML mode one of the following should happen:

Simple and linear interface are the key for defining a basic interface. Content interaction should be non-existent or limited where possible.

A WET feature may have multiple version of basic HTML interface as well of having multiple version of enhanced HTML interface.

Support for basic HTML interface are kept in scope of what browser is supported by the WET core project.



Next step