W3C

– DRAFT –
WCAG2ICT Task Force Extra Friday Teleconference

26 September 2025

Attendees

Present
bbailey, GreggVan
Regrets
-
Chair
Mary Jo Mueller
Scribe
Daniel

Meeting minutes

1.3.4 Orientation - Note 1 (Issue 779)

<bbailey> Apologies, I will have to drop just before top of hour for co-hosting WCAG2-Issues call.

<maryjom> https://docs.google.com/document/d/1VrVZkHNcoJ-DOswwCf98HBZrOqLWHhzk51kJqdqM93Y/edit?tab=t.0

<maryjom> https://docs.google.com/document/d/1VrVZkHNcoJ-DOswwCf98HBZrOqLWHhzk51kJqdqM93Y/edit?tab=t.0

[[maryjom displays wip on the google doc]]

maryjom: We agreed about copying your examples, if you change them we'll copy them back

GreggVan: Building directories -- that would be true for software and documents.
… For documents, you can have a building directory document, but for consistency I think it should be the same for all
… Fewer places where a document would be used

GreggVan: I am concern with this being an essential exception when it's really not
… There's no way for the user to make it appear in the other orientation
… So we are getting to a good place but using a faulty logic
… I whink we should put an exception on it
… WCAG2ICT -- this only applies when viewing in another angle is possible
… EN -- add a precondition that viewing in another angle is possible

maryjom: This is the pr that we have for the precondition

maryjom: Maybe "if viewed"

GreggVan: "It's possible for it to be reoriented"

maryjom: Calculators can be reoriented

Mike_Pluke: It's whether the display direction can be changed

GreggVan: The ICT under discussion is software, not calculators
… But it could be includes, you are right

GreggVan: "Where ICT includes non-web softwware that provides a user interface and it's possible for the non-web software to be reoriented" [...]

maryjom: It's possible to change the ui on the display

GreggVan: We do have the calculator problem that you are talking about

Mike_Pluke: One line of code needs to be changed (display orientation) and whether that happens automatically

[[Gregg proposes amendments in the google doc]]

<bbailey> documents do not have user interface

GreggVan: I worry about us taking the word "essential"

GreggVan: The provission says that if it's viewable in two dimensions it needs to be available in two dimensions

Mike_Pluke: Typical is not good on the precondition
… The indle example is better, as there might be the capability within the device

GreggVan: "hardware that is designed to be reoriented"

<bbailey> "software for hardware designed to be used in two orientations" is good

Mike_Pluke: I am interested in allowing screen reorientation

GreggVan: It doesn't say you have to do something automatically. Allows is a permision thing

Daniel: Sometimes you put your watch on the right/left rist and it reorients

maryjom: Are we happy with this now?

Mike_Pluke: Yes

Mike_Pluke: Digital building directory was the other change we agreed

maryjom: Yes.

bbailey: Not quite working for documents
… but I think overall it's OK
… It may still going to need additional edits

GreggVan: For preconditions we have a formula

[[Participants wordsmith in the google doc]]

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

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

GreggVan: Second to last at the bottom
… in the issue, look at SUGGESTED RESOLUTION based on the above

GreggVan: Go with CSS pixels for normative stuff
… provide fonts and distances only to provide grounding for those who have trouble with angles of view

Mike_Pluke: There's another harmonized standard for non-digital presentation
… x-height 2.7 at 400

GreggVan: That'd be a CSS of 15. What we have on the screen exactly matches that

Mike_Pluke: They say x-height of 2.7 mm ARIA 14 point at normal weight

GreggVan: This would be a 9% difference

GreggVan: We could say the minimum font size should be 14 18 points
… I am afraid it's getting pretty big
… If we were doing CSS pixels, 15 CSS pixels would be 28 points, it may be excesively large for a kiosk

<Mike_Pluke> The counter proposal to Gregg's is: Best practice is for default body text to have an x-height no smaller than that of Arial with a font-size of 16 CSS px. On a 14-inch 1920×1080 display with no zooming or scaling, this corresponds to an x-height of about 1.2 mm, which would be appropriate for a viewing distance of 40 cm.

Mike_Pluke: 16 CSS pixels was the figure wwe were discussing in this thread previously

<Daniel> s/wee/we/

GreggVan: At least we can agree on the language
… and then we can sort out the figures later

Mike_Pluke: Not comfortable with the figures
… Other expert in the field came back with another formula

GreggVan: But he contradictss ourselves. His last comment contradicts itself when he takls about x-hegiht

Mike_Pluke: But that's not specified directly
… Compared to the x-height of something else, it need to be the same

Mike_Pluke: That formulation he's been using for quite some time

GreggVan: And I don't think it's useful
… Is his more understandable than the one I am proposing?

maryjom: I'd suggest "At a viewing distance of 300mm/400"

[[Edits in the google doc]]

Mike_Pluke: At the typical vewing distance of an ATM the typical cap height should be 4.8

maryjom: Cap letter i

GreggVan: ARIAl 19 point font

maryjom: If we are not using CSS pixels, for software we should use density independent pixels

GreggVan: Nobody is using the display density that was used ten years ago

Mike_Pluke: That would date

Mike_Pluke: If we presented the two versions we have here to Phil he may be able to tell us something about them

maryjom: He's worried about the compatibility between the two specs

New notes from EN on 1.2.3 and 1.2.5

Daniel: What's the purpose of the discussion in WCAG2ICT?

Daniel: W3C/WAI doesn't support adding this note to WCAG2ICT, I will comment separately for the EN in the appropriate forum.
… Inserting audio description in the existing gaps of a video is *not* the only way to provide audio description. You can provide an alternative video or provide a separate timed text file or synched audio file. Consequently, if the video doesn't have gaps you should use the other alternatives to be able to pass 1.2.5, which is where the real

issue occurs in this context.

Audio description no pause

Description of visual information (WAI Audio/Video media guide)

Daniel had concerns about this language providing an exception where Audio Descriptions would simply not be provided at all for A/V content simply because there aren’t any or are not big enough gaps to add description. Mary Jo mentioned that there is a technique to provide a separate audio track using extended audio description where gaps in

audio are added to insert the descriptions. Conclusion is to remove references to little gaps or zero gaps from the note.

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/have/have for the precondition/

Failed: s/wee/we/

Succeeded: s/Phill/Phil/

Maybe present: Daniel, maryjom, Mike_Pluke

All speakers: bbailey, Daniel, GreggVan, maryjom, Mike_Pluke

Active on IRC: bbailey, Daniel, GreggVan, maryjom, Mike_Pluke