New SC proposal: Harmonization with other newer specifications

[momdo]

SC Shortname

Harmonization with other newer specifications

SC Text

A web page is authored in conformance with instructions, especially prohibitions, of the newer stable specification of the technology on which the page depends.

Suggestion for Priority Level (A/AA/AAA)

Level AA (or A)

Related Glossary additions or changes

newer stable specification: The latest specification document for a specific technology that is widely supported by user agents and accepted by many authors. The specification document could be a W3C Recommendation, an ISO standard or a vendor-specific technical document.

What Principle and Guideline the SC falls within.

Principle 4, Guideline 4.1

Description

Along with advances in technologies and accumulation of knowledges by the Web community, specifications for Web technologies are evolving day by day. Consequently, multiple stable specifications are introduced for a single Web technology. For example, HTML has several major stable specifications, including HTML 3.2, HTML 4 and HTML 5. Among them, HTML5 is considered as a newer and more stable specification. Generally, techniques defined in older specifications may be obsoleted in newer specifications for some rational reasons based on knowledges discovered after the publication of older specifications. For instance, HTML 5 obsoleted multiple elements defined in HTML 4 [1].
Newer specifications often strictly forbid use of obsoleted techniques. In HTML 5, for example, obsoleted elements are regarded as “non-conforming” and they “must not be used” by authors of HTML documents. Web content developers are required to follow those instructions in accordance with the meaning of requirement strength keywords (such as “should”, “must” and “must not”) defined separately, e.g. RFC 2119 [2] for W3C specifications [3] or ISO/IEC Directives Part 2 [4] for ISO standards [5]. Therefore, Web content developers need to strictly avoid use of obsoleted features in order to create contents with new technologies and with conformance to newer specifications defining those new technologies.
As stated above, early techniques are obsoleted for rational reasons, such as inefficiency or deterioration of usability. Thus, employing newer specifications and avoiding obsoleted features would improve robustness of Web contents. For this sense, conformance to instructions given by the latest stable specifications should be endorsed to Web content creators for good reasons. For the same purpose, Web content creators also should to keep their contents up to date with the latest specifications.

Note 1: Contents existing on non-rewritable media (e.g. CD-ROM) are hard to be updated. In such cases, this proposal is considered to be satisfied as long as they conform to the latest stable specifications available at the time the contents are recorded on such media.
Note 2: Some techniques in Techniques for WCAG 2.1 do and will do conflict with this proposal at present of in the future. These techniques are highly anticipated to be revised soon so that they do not conflict with prohibition by newer stable specifications.
Note 3: Each technique in Techniques for WCAG 2.1 may refer to the latest Web technical specifications in background for convenience.

• [1] http://www.w3.org/TR/html5/obsolete.html
• [2] https://tools.ietf.org/html/rfc2119
• [3] http://www.w3.org/TR/html/infrastructure.html#conformance-requirements
• [4] http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2{ed7.0}en.pdf
• [5] http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2{ed7.0}en.pdf#page=27

Benefits

By following prohibitions of newer stable specifications, it enables to avoid using obsoleted technologies (for instance, https://www.w3.org/TR/html/obsolete.html#obsolete). As a result, users can have robustness.

Testability

For HTML and ARIA, this SC can be tested by the Nu HTML checker.
In case of CSS, this SC can be tested by the CSS validator.
For other technologies, syntax checkers could be available for tests.

Techniques

G134: Validating Web pages
https://www.w3.org/TR/WCAG20-TECHS/G134
H88: Using HTML according to spec
https://www.w3.org/TR/WCAG20-TECHS/H88

---

Acknowledgement

This proposal is submitted with a private support by @makotom .

[awkawk]

@momdo Thanks for the proposal - it hasn't been adopted by the Working Group in time for the August 22 deadline for new SC in WCAG 2.1 so we are deferring it for consideration in future releases.

[makotom]

I wonder how WCAG regards latest HTML and CSS specifications.
I personally believe that, in order to enhance the enforcement of WCAG in the WWW, we should proactively embrace new specifications, such as HTML 5.1 and CSS3, and should catch up the state of the art.

I also wonder the stance towards public comments.
I heard from @momdo that he couldn't be confident that this proposal was discussed appropriately in the minutes [1] in the last six months.
It's also interesting for me that, even though the proposal itself was posted in March, it couldn't be adopted by the deadline for new SC, which was in August.
I'm sympathetic with the ones like @momdo who could not get when, where and how public comments and proposals should be posted in order to be adopted.
(FYI, @momdo is an very-active contributor in the Japanese communities for web standardizations, especially WAIC [2] for web accessibilities.)

I strongly believe that employing public comments or proposals and motivating public contributors are a essential success factor for development of the open web.

[1] https://www.w3.org/WAI/GL/minutes-history
[2] http://waic.jp/

[DavidMacDonald]

Here's a unofficial discussion of the issue, not a working group response:

To help contribute some historical context to this. There was an incredibly difficult set of discussions around validation during WCAG 2.0. After many months of heated debate the Working group decided not to require full validation, but rather only a subset in 4.1.1 of validation errors that affect people with disabilities disproportionally. The reasons were as follows:

• Many/most validation errors don't disproportionally affect people with disabilities such as users of Assistive Technology.
• Validation is a time consuming and sometimes expensive exercise, and the group was concerned that it would burn up company accessibility budgets on issues that don't help people with disabilities.
• We have instead required only the following validation rules:
  ** elements have complete start and end tags,
  ** elements are nested according to their specifications,
  ** elements do not contain duplicate attributes,
  ** and any IDs are unique,

We strongly support and encourage validation and list it as the first sufficient technique for 4.1.1
I'm guessing that these may be some of the reasons why this didn't find a champion to push it for consideration. We already considered validation in 2.0, and there does not appear to be significant new reasons to require validation. In recent years many sites don't validate, by design. And introducing this now would inhibit dynamic designs that may not be proved to have accessibility barriers.

[makotom]

Thank you for your comment, David.

Now I understand that any conformance to HTML specs would not be mentioned in main TR of WCAG
Then, I recognize that there is a space for discussions whether sufficient technique should include references to the latest HTML specs or not.

I am mentioning this as current technique does refer only to HTML 4.01 and XHTML 1.0, whereas HTML 5 and later should be regarded as a stable, robust and preferable spec, even from the viewpoint of accessibility.

[awkawk]

@makotom If you think that a change is needed in a technique you can submit an issue or even offer a pull request to show what change is suggested.

In this case, @momdo already submitted an issue (w3c/wcag#133) but the Working Group got busy with WCAG 2.1 so hasn't completed that. We closed the issue for some reason, but I haven't reviewed why yet.