– DRAFT –
WCAG2ICT Task Force Teleconference

<bbailey> gregg's email to list: https://lists.w3.org/Archives/Public/public-wcag2ict-tf/2025Sep/0008.html

Announcements

Gregg's email to list: https://lists.w3.org/Archives/Public/public-wcag2ict-tf/2025Sep/0008.html regarding changes to EN v19 that will go into v20

Comments are due by end of this meeting

Planning to deliver EN final draft v20 by end of September

bbailey: Minutes are not generating correctly.

1.4.13 Content on Hover or Focus - Note 3 (Issue 773)

<maryjom> Link to issue 773: w3c/wcag2ict#773

<maryjom> Link to PR 778: w3c/wcag2ict#778

[Mary Jo sharing screen]
… sharing PR 778

Is language currently proposed in PR 778 OK, or should we use the same language "links or other UI controls that behave like links"

bbailey: Careful to not use quotation marks unless it really is a word substitution.

maryjom to create new PR to make this change

<maryjom> DRAFT RESOLUTION: For SC 1.4.13 Note 3, and the word subtitution language, use "links or other UI controls that behave like links"

<PhilDay> +1

<loicmn> +1

<bbailey> +1

<GreggVan> +1

<Mike_Pluke> +1

RESOLUTION: For SC 1.4.13 Note 3, and the word subtitution language, use "links or other UI controls that behave like links"

<Zakim> bbailey, you wanted to ask if we have always, so far, been able to do a word substitution (and not resort to description of the change)?

<bbailey> Have we always, so far, been able to do a word substitution (and not resort to description of the change)?

bbailey: Refresh memory - have we always done word substitution - thought there was one time that we described the change
… This one is OK as a word substitution - recollection is that we had at least 1 SC where we described what it should be rather than doing word substitution.

maryjom: This was where we were suggesting possible language to the SC

1.3.4 Orientation - Note 1 (Issue 779)

<maryjom> Link to issue 779: w3c/wcag2ict#779

<maryjom> Link to PR 780: w3c/wcag2ict#780

<bbailey> s

bbailey: Thought we had closed this one out

<Zakim> bbailey, you wanted to suggest "electronic building directory" (INS electronic)

[minor wordsmithing on example for non-web documents]

Suggestion is to have the same note for non-web docs and software

bbailey: Example is more useful for non-web software only, not also for non-web docs
… Continued discussion about exception and whether it should be specific to non-web software only, or should also include non-web documents

Discussion regarding whether latest EN had changes to notes or examples for software

<maryjom> EXAMPLES: Calculators and watches would not be expected to support two orientations. Nor would building directory software written to ONLY be used on tablet devices bolted to the wall, all in the same orientation, be expected to support two orientations.

Mike to paste in what is currently in v19

<Mike_Pluke> Calculators and watches would not be expected to support two orientations. Nor would building directory software written to ONLY be used on tablet devices bolted to the wall, all in the same orientation, be expected to support two orientations.

Note is different in the EN

<maryjom> EN's note for software: Non-web software that is only used on hardware that supports a single display orientation, or where it is an application that is run only on hardware that is physically fixed in one orientation (e.g. a building directory) is covered under the essential exception and therefore does not need to provide support for orientation

<maryjom> changes

Consensus - both EN and WCAG2ICT versions of the note for software need updating
… And need to include the example from EN v19 (watches etc)

Font size items in the EN 301 549 including (4.2.2, 5.1.4, 9, 10, 11.1.4.4)

1.3.4 Orientation - Note 1 (Issue 779)

Does anyone have a problem with adding the example?
… (from Mike / EN)

<bbailey> +1 to adding example

<GreggVan> +1

<PhilDay> +1 to adding example

<loicmn> +1

Font size items in the EN 301 549 including (4.2.2, 5.1.4, 9, 10, 11.1.4.4)

<Mike_Pluke> +1

<bbailey> my (potential) concern is for hardware oriented examples under any non-web document note

EN team are also discussing text size in separate discussion

<bbailey> w3c/wcag2ict#776 (comment)

<maryjom> https://labs.etsi.org/rep/HF/en301549/-/issues/255#note_26984

<bbailey> In PR, I propose a what i think is a tidy fix: It is a good practice is for the default presentation of text to use a font with an x-height of at least 8 CSS px.

bbailey: suggested something neater in a comment

w3c/wcag2ict#776 (comment)

This is the text of the comment: It is a good practice is for the default presentation of text to use a font with an x-height of at least 8 CSS px.

Mike_Pluke: What Gregg has proposed is different to what is expected - not sure if we can go with the proposal.
… think that proposed note 3 language is better
… don't think we will use this in EN

Mike_Pluke: If we stick with CSS px as the measure - then the requirement is clear. We were trying to get consistency in 3 different places (software, web, documents). Also functional performance criteria has a similar note. Then requirement targeted at harmonising with Section 508.

5.1.4 is in pixels. 4.2.2 is in pts, but could be made in px. Then note can talk about pt equivalent.

1.4.4 is best practice - and also in CSS px, then only mentions font as an approximation. Only 4.2.2 didn't use CSS px

Mike_Pluke: 16 and 32 CSS px which were in previous notes

<bbailey> I agree that it is odd for 508 to use a measurement based on height of capital letter i -- it is so because 508 wanted to use same language as appears in ADA, and ADA specification is for displays on ATMs and fair vending machines

GreggVan: Think where we should end up - normal font is 12 pt, then zoomed to 2x that

Detlev also mentioned being careful mentioning specific font size - as it depends on viewing distance

<bbailey> I think goal is not only 12 pt minimum but also not decorative -- hence focus on x-height

We should also include "expected to be viewed at a viewing distance of ...."

Not going to come to decision today

New notes from EN on 1.2.3 and 1.2.5

Brief discussion on x.1.2.3 and x.1.2.5

<GreggVan> (that is not already in the audio), or if there are few or even zero gaps available during the video and during the credits (if any) before the video (since all gaps were utilized).

<GreggVan> Audio descriptions add descriptive information of important visual information, to the extent possible in the gaps of the audio track of the video. This is usually implemented by providing a second audio track for the audio-video media. However, this success criterion could also be satisfied by fully describing important visual information in the main audio track. Doing so eliminates the work of adding a second audio track and finding

<GreggVan> appropriate gaps in the audio to add descriptions of visual information. This success criterion would also automatically be satisfied if there is no important visual information to be described in the audio (that is not already in the audio), or if there are few or even zero gaps available during the video and during the credits (if any) before the video (since all gaps were utilized).

maryjom gave suggestion last night. Mike_Pluke then responded. Only change was to not mention SC but mention requirement (and met instead of satisfied)

<GreggVan> Audio descriptions add descriptive information of important visual information, to the extent possible in the gaps of the audio track of the video. This is usually implemented by providing a second audio track for the audio-video media. However, this requirement could also be met by fully describing important visual information in the main audio track. Doing so eliminates the work of adding a second audio track and finding appropriate gaps in

<GreggVan> the audio to add descriptions of visual information. This success criterion would also automatically be satisfied if there is no important visual information to be described in the audio (that is not already in the audio), or if there are few or even zero gaps available during the video and during the credits (if any) before the video (since all gaps were utilized).

<bbailey> https://www.w3.org/TR/WCAG22/#dfn-satisfies

<bbailey> the success criterion does not evaluate to 'false' when applied to the page

Gregg explained some minor tweaks to the above

loicmn: Further discussion about audio descriptions and gaps

<loicmn> The success criterion for video with "no audio gaps" would be 1.2.7 extended audio description

<loicmn> * I'm not available tomorrow. Sorry

maryjom: Because we still have 3 topics ongoing for discussion. Should we work on this tomorrow?