RE: 4.1.1 depreciation discussion

Thanks for that Wilco,

I also asked some of the tool testers (including Deque) what they test for in relation to 4.1.1, and got some useful information about their approaches. (Sorry for the delay.)

The type of 4.1.1 checks the tools have at the moment include:

  *   Duplicate ids, at a top level, e.g. ensure every id attribute value is unique.
Or some include checks with a narrower scope:
     *   Re-use of an ID attribute that is referenced by another element.
     *   Every id attribute value of active elements is unique.
     *   Every id attribute value used in ARIA and in labels is unique.

  *   Missing closing/opening tags (generally detected via an HTML validator)

  *   Correct tag nesting, at a top level something like elements are nested according to their specification. Or some checks with a narrower scope:
     *   An anchor or button should not contain an input, keygen, select, textarea, link or button element.
     *   List items must have parent
     *   List element must not have non-list item children

Those including tests with a narrower scope are (I think) doing so to increase the chance it will find something that impacts AT/people. E.g. an <input> nested in an <a> seems more likely to be a problem than an <article> inside a <p> or other non-interactive elements.

Some miscellaneous related items mentioned that don’t fail 4.1.1, but perhaps people think should fail something:

  *   Multiple title elements.
  *   Legend that is not first child of fieldset, or legend without a fieldset parent.
  *   ‘alt’ attributes on elements that don't support that attribute.
  *   Value applied to a role where the given role doesn't exist.

It does seem that their impact would be felt when they are failing 1.3.1 or 4.1.2. Either something is not conveyed as it should be (e.g. a list item isn’t conveyed), or an aria attribute doesn’t work (e.g. aria-describedby gets the wrong input ID).

If 4.1.1 were proposed today (with today’s browsers) there would be an argument that it creates  a lot of false positives, i.e. things caught that don’t affect people with disabilities.

I’ll add this to the github issue as well: https://github.com/w3c/wcag/issues/770


Personally, I think the need for 4.1.1 has passed and in future we should focus on the outcomes rather than the underlying technical reasons for an outcome. I.e. we should be testing that things are conveyed correctly, rather than the mechanics of the markup.

That might leave room for an SC that requires authors use specified markup patterns correctly. I.e. if you use an input, use it according to the spec. If you use an accordion pattern, does so according to the ARIA pattern spec. I haven’t thought that through completely, but hopefully it makes sense.

Kind regards,

-Alastair

--

www.nomensa.com<http://www.nomensa.com/> / @alastc