Seek comments - Basic HTML mode and progressive enhancement

[duboisp]

Latest version: https://wet-boew.github.io/wet-boew-documentation/decision/draft-2018-4.html

Your thoughts?

Issue

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.

History

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. The 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.

Rational

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

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.

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.

[nschonni]

Historically, the basic HTML mode was assumed to be the version equivalent of when the browser deactivate any javascript.

No, this isn't a noscript version of WET. The intention is to just support "basic html" features like polyfils but not complex plugins like datatables and tabs.

AFAIK, this was intended to serve as an "escape hatch" for AT users for any issues they might encounter, they can still fallback and get the content of the page.

Maybe I'm making this all up based on faulty memory, so the @wet-boew/access-working-group should probably get the final say

[duboisp]

Thanks @nschonni for the clarification.

@bsouster Can you confirm if the access working group are "ok" with that definition of Basic HTML?

[jeffreystark]

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 this spring.

There were a number of reasons why we wanted this feature including primarily
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. Even today 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.

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.

e.g.

• the tab widget becomes headings with the content of the panels
• the mega menu becomes headings, links in a list

[duboisp]

Thanks @jeffreystark, I included your comment in the documents.

[duboisp]

This was released as the design decision 4, as approved at the WET roadmap meeting on June 20.

https://wet-boew.github.io/wet-boew-documentation/decision/4.html

[jkshapiro]

I would love for us not to have Basic HTML mode at all. There's no reason for users to look for it, it shouldn't be necessary, and it has a real cost.

There's a principle known as Jakob's Law: users spend most of their time on other sites, so their experience on our site should be consistent with what's out there already. Yes basic HTML is part of Gmail's interface (because it's otherwise all custom JavaScript), but I'm not aware of any other high-traffic sites that use it. And most of the Government of Canada's web presence is entirely unlike Gmail.

Basic HTML shouldn't be necessary because we should all be doing progressive enhancement anyway, in whatever way is appropriate for our own technology stack. It's well known. And for the WET widgets progressive enhancement should be built in automatically, for those users who don't think to look for basic HTML.

The real cost shows up in testing (already a challenge in the web world, with its multitude of user agents and associated technology), in related development and debugging, and in support calls when users accidentally get into basic HTML mode and can't figure out how to get out. In short, it increases complexity. This imposes a tax on development and support teams, and since time is money, that translates to a literal increase in the tax burden on Canadians. This would be fine if it actually helped people, but as noted above I don't think it does.

We're already seeing sites that have eschewed Basic HTML, for instance Innovation Canada. Let's pave those desire paths. Or at least do some real research to determine the benefits of keeping it.

[duboisp]

Thanks @jkshapiro for your comment. But as this issue is currently closed, can you open up a new issue with your same comments to allow other wet collaborator to see and join the conversation.

The goal with this clearer Basic HTML definition is to explain that the "basic HTML mode" will be mostly taken in charge by the WET plugin itself instead of relying mostly on the web author and content expert shoulder to create compatible progressive enhancement content.