WCAG20/Institutional Memory/SC 1.3.1

From WCAG WG

Institutional Memory input for SC 1.3.1: Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

Notes from Call 13 August 2013

This topic was discussed 13 August 2013.

  • Covers many items - at the time the WG wanted to consolidate in to a general SC rather than having different SC for table structure, headings, lists, etc...
  • Wanted to avoid trying to define a list of requirements for different elements. Particularly to be technology independent it is important to not try to create a complete list of element types as we couldn't know all of the possible types for all technologies.
  • Some people want to apply this SC to form labels also.

Summary by MC: This is a wide-ranging SC that had a lot of comments filed on it and becomes a catch-all. There are areas that overlap other SC and there can be confusion about which SC applies for a given accessibility requirement (e.g., form labels). But it had to be general to be technology neutral.

GVAN

  • This is one of the two most important success criteria for AT compatibility.
    • the other being 1.1.1
    • when 4.1.2 applies it would fall into this same category (most important)
  • Any information conveyed by formatting, spacing, alignment etc needs to be conveyed in plain text or programmatically determinable under this guideline
    • Many people do not realize how much information is conveyed by layout - because whitespace is not visible to them.
  • Some things that one might think should be in 4.1.2 - we decided did not need to be there because it was covered by 1.3.1
    • I think changes in information on page was also covered here for some aspect - but I am blanking. It is the aspect that is not covered in 4.1.2 (and this is why)

Loretta

  • This was an attempt to capture mark-up requirements (e.g. use heading markup) in a technology neutral way. This is really hard.
  • It was also important that the SC only require what a technology was capable of, e.g., html has no math mark-up, but we didn't want any html page that contained math to fail automatically just because the technology doesn't provide that functionality. This is one of the reasons for the option to provide the information in text.
  • This is an area that is particularly affected by accessibility support, since we also didn't want to require mark-up that isn't supported, nor did we want people relying on mark-up that isn't supported.
  • This SC is specifically about making the information programmatically available to AT users. We assumed that it would be the user agent responsibility to customize that information as needed by the user. This has raised issues particularly for low vision users when their user agent doesn't provide the customization they want.

David

  • We were trying to reduce the number of Success Criteria, and we thought information and relationships covered a lot. I don't think any of us realized it would turn into 50% of many accessibility reports.
  • We were primarily thinking of screen readers reading headings, table headers, etc.. it wasn't really about visually recognizing things.
  • We didn't think of it as a catch all, but that is what it has become, in lot of ways.
  • The technology independent aspect of the language was very important to us, because we thought more languages would pop up, and wanted to ensure the visual representations could be picked up by screen readers.

Bruce

  • I recall that this ended up being a kitchen sink type of provison.
  • We needed a place for the data table checkpoints from WCAG 1.0 and 1.3.1 morphed into a general purpose catch all because we did not want WCAG 2.0 to have technology specific SC.
  • In general, WCAG 1.0 checkpoints became multiple SC. 1.3.1 went in the opposite direction.
  • With the benefit of hindsight, I wish we had been able to turn 1.3.1 into a Guideline with several SC under it. Such an exercise might well be impossible.
  • I understand about 1.3.1 bleeding into 4.1.2. I would characterize 4.1.2 as being in mostly in developer space, while characterize 1.3.1 is very much a practical issue for authors of static document.
Retrieved from "https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG20/Institutional_Memory/SC_1.3.1&oldid=2872"