Design decision 4 - Basic HTML mode and progressive enhancement
- Expert: @duboisp, @jeffreystark
- Status: Approved
- Type: Refine current interpretation
- Last updated: 2018-05-20
- (2019-08-21) Trivial editorial edit
- (2018-06-20) Approved at the WET roadmap meeting by including Jeffrey Stark comments
- (2018-05-17) A second expertise requested from the Web accessibility working group
- (2018-04-19) Presented at the WET roadmap meetings
- (2018-04-18) Initial draft
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.
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.
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
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:
- The initial coded enhanced interface are transformed into its basic HTML mode.
- The initial coded enhanced interface remain but it do not interfere or prevent the user to consult all the content.
- Documentation and example are available and it show what design pattern must and should be followed in order deliver the content via a basic HTML mode.
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.
- the tab widget becomes headings with the content of the panels
- the mega menu becomes headings, links in a list
- Use this interpretation for the design of WET 5 and to resolve issue relatively to Basic HTML mode.