W3C

Site Navigation

Nearby

Results of Questionnaire WCAG2ICT-SC 4.1.1 Parsing updated draft review

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: maryjom@us.ibm.com

This questionnaire was open from 2023-10-27 to 2023-11-01.

8 answers have been received.

Jump to results for question:

Review of updated proposal for Success Criterion 4.1.1 Parsing
4.1.1 Parsing bullet in SC problematic for Closed Functionality

1. Review of updated proposal for Success Criterion 4.1.1 Parsing

The draft proposal for Applying SC 4.1.1 Parsing to Non-Web Documents and Software has been updated per last week's survey and group discussion. Indicate which option you prefer to incorporate into the editor's draft and note any desired changes.

NOTE: We will be handling any WCAG 2.0 and 2.1 interpretation (if needed) separately, at a later time. There will first be some investigation into how and where that might be published.

Summary

Choice	All responders
Choice	Results
Prefer option 1, as-is.
Prefer option 1, with edits.
Prefer option 2, as is.	7
Prefer option 2, with edits.
Prefer option 3, as is.
Prefer option 3, with edits
Something else.	1

Details

Responder	Review of updated proposal for Success Criterion 4.1.1 Parsing	Comments
Phil Day	Prefer option 2, as is.	Preference: option 2, then 3. Would accept either. 3 is a bit long.
Olivia Hogan-Stark	Prefer option 2, as is.
Loïc Martínez Normand	Prefer option 2, as is.	I prefer option 2. Option 3 has implications for external bodies to do some work... I don't think WCAG2ICT is the place for this type of comments.
Mary Jo Mueller	Prefer option 2, as is.
Bruce Bailey	Prefer option 2, as is.	I prefer option 2, as is. I prefer option 1 with light editorial over option 3. My suggestion for option 1 is that it use active voice.
Mike Pluke	Prefer option 2, as is.
Sam Ogami	Prefer option 2, as is.
Gregg Vanderheiden	Something else.	All of these miss the point. SC 4.1.1 was removed because of a situation that used to exist where a) web content could be sloppy and still work because browsers repaired it but b) AT used to interpret the content themselves and were not as good at repair so the sloppy content that did not have valid syntax would break them. So this requirement was added to require that content not have sloppy syntax. It was removed from 2.2 because AT no longer interprets / parses the code themselves -- but uses the DOM created by the browsers that have "repaired" or "are able to ignore" the sloppy syntax. With regard to software -- it either works like a browser and creates a DOM or it doesn't and the contend is not sloppy because it would break the software. So 4.1.1 is no longer needed for content and would not be needed for software either unless software or non-web content is rendered by a readers that do not have a dom yet still repair the content. Unless someone knows that this is a problem (and I have not heard of it anywhere) our answer should be "4.1.1, which requires syntax of web pages not have unparseable content without repair, was required in the past (10 years ago) because AT parsed content itself and was not as good at parsing as browsers. AT no longer parses on its own and this problem no longer exists for web content. It is no longer needed in 2.2 and is also no longer needed when following 2.1 or 2.0 -- since the problem from the past no longer exists with today's AT. For software and non-web documents, there is no known problem with AT anymore either so 4.1.1 can be treated in the same way as it is in 2.2 and as it is recommended to be treated in 2.1 and 2.0 - and that is to be ignored. It does not have any effect on the accessibility of web content anymore and is not known to have any effect on software or non-web content accessibility either - so should no longer be a requirement for accessibility.

2. 4.1.1 Parsing bullet in SC problematic for Closed Functionality

The updated proposal indicates that we should remove the bullet for 4.1.1 Parsing from the SC problematic for closed functionality section. Do you agree with this approach?

Summary

Choice	All responders
Choice	Results
Yes, remove the bullet from the section.	8
No, would prefer some guidance there.

Details

Responder	4.1.1 Parsing bullet in SC problematic for Closed Functionality	Comments
Phil Day	Yes, remove the bullet from the section.
Olivia Hogan-Stark	Yes, remove the bullet from the section.
Loïc Martínez Normand	Yes, remove the bullet from the section.
Mary Jo Mueller	Yes, remove the bullet from the section.
Bruce Bailey	Yes, remove the bullet from the section.
Mike Pluke	Yes, remove the bullet from the section.
Sam Ogami	Yes, remove the bullet from the section.
Gregg Vanderheiden	Yes, remove the bullet from the section.