More colourful web with invisible design

Let the user chose between alternative expressions

My comments

In general, I would like to encourage this initiative. It would be fantastic to see it widely implemented. The major concern is about complexity. Web accessibility is still a challenge to many developers and content authors. Adding to the already substantial volume of specifications and recommendations means even more work for them. But challenges are stimulating, especially when there are obvious benefits!

Data-purpose should be standardized ASAP

In Europe, WCAG 2.1 AA is sort of mandatory, at least for public sector websites. This has many benefits. (I have spent large parts of the last five years propagating for this and helping organizations live up to the requirements.) But there are a few problems when it comes to implementation. One of them relates to the success criterion 1.3.5 Identify input purpose:

The idea behind this criterion is great. It says that the purpose of common input fields (such as email, name, street address and so on) should be specified with standard semantics. This can ensure better precision when web browsers offer auto-fill suggestions based on previously entered information. This could save time and energy for many users. Especially users with some motor or cognitive impairments. It could also reduce the number of input errors. In theory (but implementations are still rare), the browser can also, thanks to this criterion, present icons, labels or translations that are familiar to the current user. This can make forms much easier to users struggling with understanding the default written labels.

Currently, however, the only recommended way to fulfill this criterion is by using the autocomplete attribute. This means that web browsers can remember data that the user enters. The criterion expressly states that it applies to information about the user, so the data will often be Personally Identifiable Information.  Ideally, users do not share the same browser storage, but in reality, users borrow computers from each other, from libraries and from other places. Sometimes without logging in with their own account. Thus data in autocomplete fields can leak to unintended recipients. Therefore, we as consultants must advise web developers to always consider using the autocomplete=”off”, despite the many benefits. (By the way, this caution, in my opinion, should be written into the Understandingdocument.) The new specification proposes a new attribute, data-purpose, that will make it possible to combine the advantages of personalized presentation (eg. familiar icons) with privacy protection:

autocomplete=”off” data-purpose=”cc-number”

This is, in my opinion, a significant contribution in the proposed specification.

The only trouble: It does add code complexity and to the body of knowledge that web developers need to be familiar with.

The data-action, data-destination and data-simplification attributes seem like great ideas

While all standardization adds complexity, I can see great value in enabling content editors to add standardized in-page semantics for link destinations and button actions. Except for explanatory symbols and tooltips, such metadata could be used to duplicate essential features from the page in the browser chrome, and/or enable web browsers to offer shortcuts similar to the old accesskey attribute, but in a more consistent manner across the web.

The data-simplification is another great possibility. Let’s hope it will be widely implemented, both by content authors and user agent designers!

How are the lists of standard values to be maintained?

It can be expected that new values will be needed, as technologies and user behaviors change over time. Should the W3C regularly update the specification, or is it better to point at a list maintained externally by, for example, IANA or some community effort that could update the list continuously?

Update: This question has been answered by a member of the Task Force.

I hesitate about supporting data-distraction and data-symbol

The data-distraction attribute is proposed as a way to declare, for example, when non-essential content includes distracting animation or sound. Intentions are good, because many users struggle with focus, but there are already requirements in WCAG that address such needs. I doubt many content authors will happily declare part of their design as non-essential distractions. This reminds me of the old P3P standard intended to facilitate configuration-based filtering of web content based on privacy protection. Many websites published empty or misleading P3P metadata with the only intention of NOT being blocked by user preferences.

An attribute not expected to be used as intended probably does more harm than good, in part because it adds complexity to the overall specification. Developers and content authors already have a lot to learn. You should be able to publish on the web without first getting a degree in information modelling.

The data-symbol attribute is meant to enable editors to indicate that a certain symbol could be used to present the element. Again, I support the underlying objective here: Supporting users who need to complement text or layout with symbols. But this objective, as we have seen already, is partially adressed by the data-purpose, data-destination and data-action attributes. In order not to make the specification more complex than needed, perhaps the symbol attribute could be postponed to a potential future version of the specification, in case the use of complementary symbols proves popular. (I am not sure if this is a good idea, but would like to ask the question.)

There’s more

One of the specifications, the Personalization help and support 1.0, includes a number of other great proposals for in-page metadata. This includes, among other things, a way to offer alternative content for users struggling with numbers or requiring easy-reading or literal language (no idiomatic expressions, for example). The comment period for this specification ended last summer.