Meeting minutes
<Daniel> Dtte: 9 October 2025
Announcements
Changes from today - should be final changes to then lead to AG WG review of editor's draft, then prepare for publication
Should we delay by a week to wait for any input from EN?
Getting close - we may just put the notes in for AG WG review and keep things moving
Mike_Pluke: Can't remember exact date of EN review meetings.
… Procedural side of things is less clear
A lot of these PRs are to match recent comments on v20 of EN
… improvements to the notes.
1.2.3 and 1.2.5 (audio description SCs) - PR 789
PR: w3c/
[Mary Jo sharing screen, currently showing list of PRs]
<maryjom> Link to issue 786: w3c/
Example of change - more detail on note around audio descriptions.
Original:
div class="note wcag2ict">
The WCAG 2 definition of “audio description” says that “audio description” is “also called ‘video description’ and ‘descriptive narration’”.</div>
Proposed change:
<
Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") add descriptive information of important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be needed at all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio-video media.</div>
Same note is used 1.2.3 and 1.2.5, and replaces additional notes in both that gave alternate names
Mike_Pluke: Question - this was being updated while changes were also happening in EN, and cannot therefore remember if this is incorporated into EN (especially notes 1 and 2).
<Zakim> bbailey, you wanted to discuss minor typo on #789 (add -> adds)
<maryjom> DRAFT RESOLUTION: For SC 1.2.3 Remove notes 1 and 2, and for SCs 1.2.3 and 1.2.5 add the new note as-is.
<PhilDay> +1
<Mike_Pluke> +1
<bbailey> +1
<loicmn> +1
<GreggVan> +1
Daniel: Checked that change has already been made as per suggestion.
maryjom: Already adjusted
RESOLUTION: For SC 1.2.3 Remove notes 1 and 2, and for SCs 1.2.3 and 1.2.5 add the new note as-is.
1.3.4 Orientation - PR 780
PR: w3c/
<maryjom> Link to issue 779: w3c/
Made adjustments to the precondition to cover hardware that is just designed for a single orientation. Examples from EN have also been added.
Proposed change: ###### Applying SC 1.3.4 Orientation to Non-Web Documents
Where the non-web document is displayed on hardware that is designed to be reoriented in typical use, this applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4.
<div class="example wcag2ict documents">
A non-web document that is only used on hardware that supports a single display orientation, or is only displayed on hardware that is physically fixed in one orientation (e.g. a digital building directory) is excluded by the precondition and therefore does not need to provide support for orientation changes.</div>
###### Applying SC 1.3.4 Orientation to Non-Web Software
Where the non-web software is displayed on hardware that is designed to be reoriented in typical use, this applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4.
<div class="note wcag2ict software">
Non-web software that is only used on hardware that supports a single display orientation, or where it is an application that is displayed only on hardware that is physically fixed in one orientation (e.g. a digital building directory) is excluded by the precondition and therefore does not need to provide support for orientation changes.</div>
<div class="example wcag2ict software">
Examples of software that is excluded by the precondition:
- The software on a typical handheld calculator (one that typically would only be used in one orientation)
- Software used on wristwatches (where the software typically is only displayed in one orientation) (sleep mode being non-typical)
- Building directory software written to ONLY be used on tablet devices bolted to the wall, all in the same orientation
</div>
maryjom: May need a script adjustment as the example doesn't seem to show that it applies to non-web documents
maryjom to follow up with Daniel
Are all happy with the textual changes? Formatting can be fixed by editors & Daniel
<bbailey> Preview diff: https://
<maryjom> DRAFT RESOLUTION: For SC 1.3.4 merge PR #780 into the editor’s draft as-is
<bbailey> +1
<loicmn> +1
<GreggVan> +1
<Mike_Pluke> +1
<PhilDay> +1
RESOLUTION: For SC 1.3.4 merge PR #780 into the editor’s draft as-is
1.4.4 Resize Text - PR 792
PR: w3c/
Discussion last week was that adding this new note goes beyond our remit for WCAG2ICT - which should just be commenting on WCAG. Fine for EN to add it - but may be a step too far for us to add.
This is the note that could be removed:
div class="note wcag2ict software">
For non-web software expected to be viewed at a distance of approximately 15 3/4 inches (400mm), good practice is for the default presentation for text to have an x-height that is at least as big as Arial font at 16 CSS px, which at 200% zoom would be 32 CSS px.</div>
bbailey: Think it is better to leave it out at this stage
<bbailey> Note was mixing absolute measurements with relative (CSS px). I am happy to have EN 301 549 work it out.
Mike_Pluke: Agree to leave it out in WCAG2ICT. Zoom won't help if you have extremely small fonts on the web page, so it was added to the EN. It should be addressed in WCAG first if WCAG2ICT should then cover it.
GreggVan: Suggest we pass this on to the WCAG3 group - or WCAG2 backlog
maryjom Or add a note into the understanding section
maryjom to open issue on WCAG 3 or understanding on WCAG2
<maryjom> DRAFT RESOLUTION: Update SC 1.4.4 to remove the note on minimum text size
<PhilDay> +1
<loicmn> +1
<bbailey> +1
<Mike_Pluke> +1
<GreggVan> +1
RESOLUTION: Update SC 1.4.4 to remove the note on minimum text size
2.4.2 Page Titled - PR 793
PR: w3c/
<maryjom> Link to issue 627: w3c/
Was briefly discussed last week.
<maryjom> Old PR was PR 633: w3c/
We did have an old PR where the content for software was agreed. However, there were merge conflicts with this so we closed the old PR and created a new one with the same changes
This splits the guidance for non-web documents and software
Daniel made a slight change
(removed title attribute, changed to semantic title)
Additional paragraph only appears for software, not for documents
2 changes proposed by Daniel.
First was changing title attribute, changed to semantic title
Daniel
Daniel: Happy - changes are in PR comment
bbailey: See recommended word substitution for non-web software. See same thing in documents
… but think we should have the same in documents
bbailey: You explain the problem for non-web docs - but don't give an alternative
GreggVan: Think we should not have this for non-web docs
<maryjom> Daniel's suggested alternate requirement: **2.4.2 Non-web Document Titled:** In non-web documents implemented on a platform that supports title attributes for windows or screens, titles are provided that describe the topic or purpose of the non-web document.
GreggVan: We decided that we should not have this in documents - in the last meeting. Not all documents have this so we shouldn't comment on it. You also can't put titles in some documents without breaking copyright.
… Also no way to do it on a text file.
… so should not apply / voided
Daniel: Agree this should be voided in EN, but scope is different in WCAG2ICT. We still need to say something for the cases where it does apply.
Mike_Pluke: Agree in principle that voiding is a good idea. However concern at this stage - is it easy to do that at this stage in the process (as the previous version of EN had it).
<bbailey> FWIW, 2.4.2 not voided is Section 508
Mike_Pluke: Currently a proposal to void it in EN - it may end up staying in EN
Daniel: Edited my suggestion to no longer reference windows or screens
New version from Daniel: **2.4.2 Non-web Document Titled:** In non-web documents implemented on a platform that supports semantic title attributes for documents, titles are provided that describe the topic or purpose of the non-web document.
GreggVan: Documents don't exist in an environment. You can't say what environment/platform they are implemented in.
… It should not apply - it's a mistake - we should correct it
<bbailey> I am okay with (1) daniels proposed edit, (2) saying it should not apply, (3) saying applies to non-web documents as written.
<bbailey> I am not comfortable with just having a gap space (as is in 793 at present).
Daniel: Gregg's first point - in a platform - we could talk about an authoring tool.
When it applies - we had a similar discussion on software. WCAG2ICT is a guidance document -we can give notes or guidance, but we should not just say it does not apply.
We have a similar approach in software - where it applies, do XYZ
GreggVan: This doc (WCAG2ICT) is not an explainer for WCAG. This is meant to apply WCAG - and is for others who create regulations and want to apply WCAG to other ICT
<Daniel> Quoting from WCAG2ICT -- This document provides informative guidance (guidance that is not normative and does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) to non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG
<Daniel> 2.0, WCAG 2.1, and WCAG 2.2, which are W3C Recommendations). Specifically, this document provides informative guidance on applying WCAG 2.0, 2.1, and 2.2 Level A and AA success criteria to non-web ICT, specifically to non-web documents and software.
maryjom: This is the kind of discussion that we had on EN on the side. There were some examples of things that could not have a semantic title (like a plain text document).
… Another example - content management system
… Movies are documents - but name of movie may not be a semantic title. Same for other forms of art - it may not have a meaningful name
Daniel invited to state case
Daniel: Happy to add the examples which would explain the scenarios.
<maryjom> POLL: I am okay with (1) daniels proposed edit, (2) saying it should not apply with examples of why (3) saying applies to non-web documents as written
<GreggVan> 2
<loicmn> 2
<bbailey> 2 > 1 > 3
<Mike_Pluke> 2
<GreggVan> This does not apply to non-web documents in general for a number of reasons including but not limited to
I'll abstain - I'm not sure what I think!
<Daniel> 1
bbailey: Agree that 2 is a risk and we have not done it elsewhere. Would rather we took a similar approach as we have in other places.
maryjom to come up with alternative wording
We do not have resolution for this one - maryjom will make some changes to the PR
<bbailey> for next time, maybe poll on which options people would object to ?
Also didn't get the last topic (3 flashes)
bbailey: Sometimes when we get stuck - it can be helpful to differentiate between something that can be tolerated vs not
We will pick these last 2 topics up next week
<GreggVan> This does not apply to non-web documents in general for a number of reasons including but not limited to 1) not all documents formats support this including txt files so - in combination with the existing requirements in accessibility standards that you cannot lose accessibility information in document conversions would mean that one could not ever convert any document to txt format without violating one or the other provision 2) not all
<GreggVan> document storage formats support it 3) this includes movies and art -- and there may be copyright issues in naming these with some other name (e.g. a piece of art named "untitled"
GreggVan: Made a suggestion to be discussed next week
Daniel: Doesn't apply - should use different language - problematic to apply
GreggVan: OK to use problematic to apply