Meeting minutes
Announcements
EN 301 549 team have been working hard to incorporate WCAG2ICT changes
ITI have also submitted more comments along with a few others
Mike & team have been working hard on latest edits
Stationary ICT issue is still a hot top for EN - 2 opposing camps with opposing views.
Daniel: is v16 in the GitLab?
Mike_Pluke: v17 which fixes some of the issues in v16 - now on GitLab
Mike_Pluke: There is another meeting to discuss stationary ICT issues - remainder is close to completion.
… Difficult to predict how close we are to completion
maryjom: W3C AG WG related - WCAG3 has been updated to incorporate latest work.
… Incorporated a number of PRs.
bbailey: It's not a formal release - it's on the TR track - not a public draft for comment yet
Potential changes due to AG WG review - Issue 772
<maryjom> Link to issue 772: w3c/
<maryjom> Google doc: https://
Google doc was used for working on proposals
There are comments in both the issue and the google doc
Comments that were made were not something that would block publication, but wanted the language refined. That is what we are trying to do in this issue
Part was changes to introductory text
bbailey: recollection was that proposal 3 was slightly preferred, but there were some aspects of 2 that seemed better
3 was developed further on the call last week.
bbailey: Thought that Gregg was going to wordsmith after the call last week - not sure if this has happened.
[Mary Jo looking at issue w3c/
Comments from Gregg in the issue - looked like they were before the call last week. May have been a subsequent email from Gregg.
<Zakim> loicmn, you wanted to say Gregg has worked in the Google doc
loicmn: Gregg has been working in the Google doc - this has a new section that would be worth looking at (entitled Total Rethink).
bbailey: I don't think we are just talking about modern pinch-to-zoom devices - we should also consider other devices
Mike_Pluke: Last update in EN (v17) - Gregg was obviously aware of this issue - now trying to check if any of these options are in v17. Struggling to find them
v16 used what we had published in WCAG2ICT
Intro text is not in the EN. However, some of the comments in "Total Rethink" have a bigger impact.
Text from latest v17 of EN.
10.1.4.4 Resize text
Where ICT is, or includes, a non-web document,
the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.4.4 Resize text.
NOTE 1: Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such viewers or editors, unless the content will not work with that zoom feature.
NOTE 2: It is best practice to use only fonts that allow for scaling without loss of quality (e.g. pixelized presentation). This applies in particular to embedded fonts.
NOTE 3: Best practice is for the default presentation of text to have an x-height of at least 1.2mm. For a 14 inch screen at 1920 x 1080 screen resolution with no zooming or display scaling, this means the x-height of the text needs to be at least as big as Arial at 16 CSS px.
11.1.4.4 Resize text
Where ICT is, or includes, non-web software that provides a user interface, and is not closed to enlargement,
the non-web software shall satisfy the success criterion in Table 11.2.
Table 11.2: Non-web software success criterion: Resize Text
1.4.4 Resize Text: Except for captions and images of text, text can be resized without loss of content or functionality and without assistive technology either up to 200 percent or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform.
NOTE 1: The Intent section in Understanding 1.4.4 Resize Text refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the non-web software provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality, or that
the non-web software works with the platform features to satisfy this success criterion.
NOTE 2: For non-web software, sometimes the platform provides text scaling to 200% for most, but not all text (e.g. headings, which are naturally large, may not be increased in size to 200%, but other text does increase to 200%). In such cases, authors would only need to support text scaling to the extent provided by user settings in the platform,
without losing content or functionality, to satisfy this success criterion.
NOTE 3: This requirement is based on WCAG 2.2 Success Criterion 1.4.4 Resize Text but has been modified to make it more relevant for non-web software where resizing capabilities may be partly limited in the platform software functionality.
NOTE 4: Good practice is for the default presentation for text to have an x-height that's at least as big as Arial at 16 CSS px.
<maryjom> https://
bbailey: v17 version doesn't address Jon's comment -it uses the previous WCAG2ICT text
<Daniel> https://
Link from Daniel is the previous week minutes
Jon's comment is addressed by Proposal 2
So EN may not have to change if we go with Proposal 2
Gregg's proposal 3 modified the actual SC text
bbailey: Having just re-read the minutes and the google doc, we now have 4 options that we are aiming for. Google doc is the latest version
… and believe that this latest version does address Jon's concern
bbailey: case of 'dumb' phones should have a system setting for resizing text - even if they don't have a zoom.
bbailey: Would prefer to have mention of 3/8" text kept in note 4 of 1.4.4 - as it is more likely that people will find it here. We could also mention it in closed functionality as well if we prefer
<maryjom> Poll: Which proposal do you prefer? 2, 3 or 4 or something else?
Proposal 4 is what Gregg suggested under the heading paragraph starting "So I suggest"
Headings now modified in Google Doc.
<GreggVan> can you post the link to the choices
Choices are in Google doc https://
Proposal 2 - from Jon's comment
Rewords the second from the last sentence starting with "A reasonable expectation..."
This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Non-web software needs to work with platform capabilities where they exist, but when the platform has text resizing that up to 200%, but not all text types scale to 200%,
it is unreasonable for all apps on a particular platform to be required to build in their own text resizing. A reasonable expectation would be fFor non-web software, where the platform has text resizing support up to 200%, but where not all text resizes to 200% of it's default due to the resized text already being 200% of the default body text
size, resizes to the extent the platform provides. Doing so would still address the user needs identified in the Intent from Understanding Success Criterion 1.4.4. The following criterion is recommended as a substitute for the WCAG language:
Proposal 3 - From Gregg’s comment in the new issue
Here is a variation on that -- that I think covers all the angles including places where no resizing is needed to achieve the same thing as 200% increase over normal sized text.
This success criterion is problematic to apply directly to non-web documents or software when the user agent or platform does not provide text enlargement features that increase all displayed text to 200%. For example some mobile platforms do not provide built-in utilities to allow scaling of all text to 200% whereas all browsers did when the SC
was written - and the intent when the original SC was written was to support and not interfere with that (not require software to provide their own). However, if there is no scaling function in the platform at all, then text scaling should be provided to ensure that text is large enough for those with 20/40 vision (the equivalent of 200% of 20/20).
Note that this success criterion also has special considerations for ICT with closed functionality. The following criterion is therefore recommended as a substitute for the WCAG language when applying to non-web software:
Except for captions and images of text one of the following is true:
a) text can be resized without loss of content or functionality without assistive technology up to 200 percent using text resizing functionality of the platform or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform, or
b) if the non-web software is designed to work on a platform that has no text resizing capabilities, or that functionality is not exposed to the user when using the software, text can be resized without loss of content or functionality without assistive technology up to 200 percent using text resizing functionality of the software, or
c) the platform has text resizing support that enlarges all text is up to 200% of the size of the default body text or larger and that feature is supported, or
d) software is running on a known hardware platform and all text is already known to be 3/8 of an in or larger in size.
Proposal 4: Re-thought suggested text
FOR NON-WEB DOCUMENTS — we go with just
10.1.4.4 Resize text
Where ICT is, or includes, a non-web document,
the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.4.4 Resize text.
NOTE 1: Content for which there are software players, viewers, or editors, or platforms with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with the zoom feature.
NOTE 2: It is best practice to use only fonts that allow for scaling without loss of quality (e.g. pixelized presentation). This applies in particular to embedded fonts.
NOTE 3: For ICT where the absolute size of the text can be controlled, it is best practice is for the default presentation of text to have an x-height of at least 1.2mm. For a 14 inch screen at 1920 x 1080 screen resolution with no zooming or display scaling, this means the x-height of the default text before zoom needs to be at least as big as
Arial at 16 CSS px, and if zoom is not provided, the minimum size of the text in at least one setting would be 2.4mm or 32 CSS px.
FOR NON-WEB SOFTWARE — we go with just
11.1.4.4 Resize text
Where ICT is, or includes, non-web software that provides a user interface,
the non-web software shall allow text to be resized up to 200% without loss of content or functionality, except where the absolute size of the text is known or controlled by the software and the minimum font size is already 2.4mm or larger
NOTE 1: The Intent section in Understanding 1.4.4 Resize Text refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the non-web software supports the zoom features of the underlying platform software or that the non-web software provides some means
for enlarging the text to 200% without loss of content or functionality.
NOTE 2: The techniques for 1.4.4 Resize Text list the normal Zoom feature of browsers and platforms to be sufficient to meet SC 1.4.4 and to not require that the Zoom feature wrap the text. A pinch zoom feature such as is found on mobile phones would meet this description if they allow zoom of at least 200%.
NOTE 3: Some applications such as kiosks or digital signs already have print that is larger than 200% of typical body text. Where their minimum text size is already known and of large print size, this requirement does not require additional zoom.
NOTE 4: Some applications do not allow access to the underlying platform zoom features or run on platforms without an underlying zoom feature. If their minimum physical font size is not known or is less than 2.4 mm, then the application would need to provide a feature that provides 200% zoom or creates a known minimum font size of 2.4mm.
NOTE 5: Good practice is for the default presentation for text to have an x-height that's at least as big as Arial at 16 CSS px so that it is 32 CSS after 200% zoom.
<GreggVan> you can use any letter you want
Question on Gregg's new proposal 4 - convert mm
<GreggVan> .7 mm = 12 pt type
<GreggVan> typo
<GreggVan> I can hear but not talk
3/16" = 4.8mm. This is from Section 508 and ADA section 707.7.2
<GreggVan> Yep
<bbailey> https://
<GreggVan> but my retort will be on record.
<bbailey> 707.7.2 Characters
<bbailey> Characters displayed on the screen shall be in a sans serif font. Characters shall be 3/16 inch (4.8 mm) high minimum based on the uppercase letter “I”. Characters shall contrast with their background with either light characters on a dark background or dark characters on a light background.
<GreggVan> that was typo
Text size in Gregg's proposal 4 has just been changed to 3/16" or 4.8mm as the minimum size.
<GreggVan> 1 point (pt) = 1/72
<GreggVan> when they say 12 pt = 1/6 inch ≈ 0.1667 inches
<GreggVan> 12 pt ≈ 4.23 mm
bbailey: 4.8mm would be for size of capital letter. Gregg's previous version referenced X-height which is a different measure
<GreggVan> 12 pt = 1/6 inch ≈ 0.1667 inches ≈ 4.23 mm
<GreggVan> when you say X height you mean the capital letter always
https://
<GreggVan> it doesnt
x-height refers to the height of the lower case x
<GreggVan> 18 pt is mimimum Lprint according to APH
Mike_Pluke: Seen some confusion between CSS pixels, pts and pixels. It does get confusing
<GreggVan> it the question is when do you NOT need to have enlargement it shoud be 18 point or larger
<maryjom> Poll: Which proposal do you prefer? Proposal 2, 3 or 4 or something else?
<bbailey> I believe the the ADA metric works out to nominally a 16 point font size.
<GreggVan> 18 pt = 0.25 inches
<GreggVan> 18 pt = 6.35 mm
<GreggVan> 16 pt ≈ 0.222 inches (2/9 in)
<GreggVan> 16 pt ≈ 5.64 mm
<GreggVan> but I think 16 pt is too small for not having enlargement
<bbailey> Typographical font size is not the same as "upper case letter i" !
<loicmn> 4, with size corrected to 18pt = 6.35 mm
<Zakim> bbailey, you wanted to say i prefer keeping (d)
<Daniel> s/miximum/maximum/
Mike_Pluke: Looking at EN for closed functionality. Best practice 32 CSS pixels, 24 pt. But actual requirement is expressed in terms of viewing distance
<GreggVan> 20 pt is 7mm
Mike_Pluke: and EN uses capital H, not x-height
… or capital I height (as per section 508)
<bbailey> https://
<bbailey> large scale (text)
<bbailey> with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts
Mike_Pluke: minimum size does vary depending on viewing distance - as per EN.
<bbailey> i agree the fixed size should be one of a few options
maryjom: So maybe we shouldn't be introducing an exception with fixed size.
GreggVan: Think we should include an exception for kiosks - it's very difficult for them.
maryjom: That is already covered in closed functionality - it is problematic - and you can reference other sources like 508, ADA, or EN 301 549 to find the minimum text size.
GreggVan: This is not talking about word wrapping - pinch zoom satisfies this.
maryjom: There are old style phones that don't have pinch to zoom
<Zakim> bbailey, you wanted to say where I was saying 16 point (in a word processor) is 3/16 inch "uppercase letter i" that I should have been saying / writing 18 pt.
bbailey: if you get a brand new flip phone - has a setting for fonts - and the largest font you can pick is 2x larger than the smallest font.
Gregg: If it doesn't run anyone else's software (apps), then it is already a closed system.
bbailey: Hoping that we don't have to fail software written for an old-school flip phone or kiosk
… But also don't want too much of a loophole
<bbailey> Apologies, it is 16 point for "uppercase letter i"
<bbailey> https://
<bbailey> From that page:Why 3/16 inch?
<bbailey> Accessibility regulations specify a measurement of 3/16-inch-high minimum based on the uppercase letter “I,” which is not a metric traditionally associated with typography. This is because the regulation must work “in the field” for third-party testing. For most typefaces, this works out to 16 pt.
<bbailey> But I wrote that and asked a couple people to check my math.
<bbailey> 16 point is a very common size for "large print" books.
<bbailey> I agree that proposal 2 is a minimal edit
maryjom: will send an email summarising this to try and get consensus on this prior to the meeting next week
<bbailey> IMHO proposal 2 addresses the concern Jon A raises, and that that Jon A raised is worth addressing.