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://
<maryjom> https://
[[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://
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.
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.