Meeting minutes
issue 196
<maryjom> w3c/
Related discussion: https://
<maryjom> https://
Mitch has come up against this - conferencing software that was on web and native. Web version was more accessible than native, so were not sure if native app had to be made more accessible, or if they could rely on web
Brief discussion about adding note in Applying "conforming alternate version" ...
Adding a note would be nice to do if we can do it without adding more confusion, but not if it may cause other issues.
Examples: using accessible web page as an alternative for non-web document (like PDF), or non-web software. This does happen now.
But less likely: a non-web software that is an accessible alternative to an existing non-web software.
May be wiser to just not comment on this whole area, and leave the current non-statement as is.
Current text in the editor's draft: https://
Applying “conforming alternate version” to Non-Web Documents and Software The guidance in this document does not use the term “conforming alternate version”. See the section Comments on Conformance.
Consensus: leave existing guidance as is. Not currently used in this document, and not planning to add the WCAG section that does use it.
Issue on WCAG3 should be raised if one does not already exist to update this definition. This is outside the scope of WCAG2ICT
issue 200
CSS Pixels: Verify how density-independent pixels behave in Windows and Mac
This can be closed as it is now addressed in the latest updates to CSS pixels. Also we don't give specific techniques.
Was split out from broader comment: w3c/
Refer to w3c/
Issue closed.
issue 266
AG WG Review: 4.1.1 Parsing WCAG2ICT guidance
<maryjom> g-to-non-web-documents-and-software
<maryjom> https://
comment was regarding our 2.0 and 2.1 guidance. 2.2 guidance was OK
Gregg's proposal for applying 4.1.1 "In places where markup languages are used outside of the web, and where assistive technologies read the markup languages directly, then 4.1.1 would apply to software and non-web documents as written in 2.0 and 2.1. with content replaced with software and non-web_documents. ...
… NOTE: 4.1.1 is no longer required for web content because assistive technologies do not access the markup languages directly anymore but rather use the browsers which repair the content markup errors that caused problems for assistive technologies. "
From comment: w3c/
New guidance with Gregg's comments included in context:
WCAG 2.0 and 2.1 Guidance: WCAG 2.0 and 2.1 are incorporated, either directly or by reference, into other standards. Therefore, the application of 4.1.1 Parsing to non-web documents and software is to follow the new guidance provided in the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata which states the following: ...
… This Success Criterion should be considered as always satisfied for any content using HTML or XML. ...
… In places where markup languages are used outside of the web, and where assistive technologies read the markup languages directly, then 4.1.1 would apply to software and non-web documents as written in 2.0 and 2.1. with content replaced with software and non-web_documents. ...
… NOTE 2 As in Web content, 4.1.1 Parsing is not known to have any effect on the accessibility of non-web documents or software. There are no known examples of non-web documents or software that would have an issue such as those covered by 4.1.1 Parsing. ...
… Modern assistive technology does not parse document or software markdown languages for accessibility information. User agents and platforms used to render non-web documents and software use platform accessibility APIs to present accessibility information to AT. Therefore, 4.1.1 Parsing would no longer be a requirement for accessibility. ...
… NOTE 3 Where an existing standard requires 4.1.1 parsing for non-web documents and software, this Success Criterion would be automatically satisfied.