Meeting minutes
<Chris_Loiselle> Hi all, I would scribe but need to trust IRC, it keeps dropping. Thanks for the welcoming!
Announcements
<bbailey> https://
EN v16 draft is out (EN 301 549). Comments due by this Sunday
<bbailey> Woot!
WCAG2ICT was published on 21 Aug. We still have more work to do - but that was good progress
<maryjom> https://
Published version - see link
<maryjom> WCAG2ICT overview page: https://
Also updated the overview page
GreggVan: new EN draft is out. Do you have a link?
<bbailey> I am happy to see that previous URL works as expected: https://
Don't think it is uploaded - was sent via email.
TF welcome Chris
AG WG comment: 1.4.4 Resize Text
<bbailey> w3c/
We did have comments on resize text - didn't block publication, but we still want to review the feedback
Issue 772 took comments from the AG WG general review thread, and also added some proposals for revised language
[Mary Jo sharing screen, currently showing issue https://
Introductory language - some concerns were expressed.
<maryjom> Proposal 0: 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
<maryjom> 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 for non-web software to work with the text sizing features to the extent the platform provides. Doing so would still address the user needs identified in the Intent from Understanding Success
<maryjom> Criterion 1.4.4. The following criterion is recommended as a substitute for the WCAG language:
Latest from v16 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 players, unless the content will not work with zoom.
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.
WCAG2ICT TF - we modified the SC. Looks like the EN committee didn't take this change - probably as they were focusing solely on the latest comments rather than making new technical changes.
The issue (772) concerned the introductory text along with one of the notes
Jon's proposal rewords the penultimate sentence (proposal 2). Gregg's (proposal 1) rewords most of the paragraph.
Gregg also added proposal 3 with further refinements
Proposal 0 - Current language in WCAG2ICT
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 for non-web software to work with the text sizing features 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 1 - from Gregg's comment
Modifies most of the introductory text.
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%. Some platforms such as 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. The
task force felt that the intent was to support scaling up to at least 200% by the platform, not to require that all software provide its own scaling function. 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 recommended as a substitute for the WCAG language:
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 for 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
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 software when platforms do 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 therefor 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.
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
c) 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.
Gregg: This was written way back when - so can comment on that, and talk about the assumptions about 200% in all browsers. We are now talking about non-web content.
If it is all on a kiosk or something and it already has very large text - then there shouldn't be a requirement to also provide additional zoom.
3rd option - if there is no zoom on the platform - then you don't have to do anything (particularly in a closed system that doesn't allow access to any accessibility features).
Gregg: This is complicated; I've tried to cover all possibilities but it is rather complex and is therefore a little longer
<PhilDay> +1 to Gregg's proposal 3
maryjom to poll options
<maryjom> POLL: Which proposal do you prefer? 0) Proposal 0 – leave as-is, 1) Proposal 1, 2) Proposal 2, or 3) Proposal 3, or 4) something else
3, but would also accept 2 or 1
<GreggVan> 3
<Chris_Loiselle> Per what Gregg shared today, I lean to proposal 3
bbailey: Nice to use somebody else's suggestion. Jon's edit was fairly minimal over the previous suggestion which is nice, but Gregg's proposal 3 is more complete.
maryjom: Suggested next stage is to put in a PR and allow wider TF to review.
maryjom: Think that we can't get this into the EN at this late stage - only comments that are being accepted are updates to previous work.
<bbailey> I like Gregg's Proposal 3 but it seems to be missing Jon's key addition: 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
<Zakim> bbailey, you wanted to discuss another comment
bbailey: Another argument for using Jon's proposal as it is less change.
maryjom working on tweak to proposal 3 to address bbailey's concern above
<maryjom> For example some mobile platforms provide built-in utilities to allow scaling of some, but not all text to 200%, whereas all browsers did when the SC was written...
<maryjom> For example some mobile platforms provide built-in utilities to allow scaling of some, but not all text to 200%, whereas all browsers did scale all text to 200% when the SC was written...
GreggVan: Agree with the wording - but put it in the exceptions (a-c)
<bbailey> I think all these are just for non-web software and we don't say anything for non-web documents.
maryjom: We didn't pull this one into separate sections for non-web documents vs non-web software
<Zakim> PhilDay, you wanted to suggest we could just add or documents in the introductory paragraphs
Discussion ensued on whether this should also apply to non-web documents. If you embed code in a document, does it become software?
PhilDay: suggest we just add non-web documents or software
<maryjom> 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%.
<PhilDay> +1 to maryjom's modified text
ack
bbailey: can we move on and come back to this later in the meeting?
[maryjom adding Google doc to help with editing this introductory text to resize text]
<bbailey> Current phrasing seems to miss that SOME text must increase to %200 (or min 3/8).
<maryjom> Google doc: https://
Gregg has done a modified version to address Jon's comment
(Replaced proposal 3 with a new edit)
<bbailey> +1 to Proposal 3 (with its four options)
Gregg's latest edit (taken from google doc):
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.
Chris_Loiselle: Gregg's point - the OS on mobile - should be held responsible for meeting this. We don't have to provide an exception. What we are writing here makes sense.
… Don't want to give an exception along the lines of "if you OS doesn't support it, then you are OK..."
maryjom: How do we cover the fact that mobile apps don't have to provide additional zoom in addition to the platform
Discussion about pinch-zoom in mobile. Is pinch-zoom AT? This requirement is without AT.
GreggVan: AT is not all the accessible features of the platform
Chris_Loiselle: Remember we discussed accessibility features vs AT. Pinch zoom is a feature, not AT.
What Jon was mentioning was lived experience of what could be considered as AT.
The other topic was possible adjustments to notes
Notes 3 & 4 became similar
2. Possible adjustments to the notes
Jon expressed concern about the notes, but we had made some adjustments so it's difficult to tell what might need changing. We currently have 2 notes that are similar to what he commented on - Notes 3 and 4
Note 3 (Added) (for non-web software)
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 4 (Added) (for non-web software)
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.
Gregg: references sufficient techniques for resize text - which says that zoom features pass
… from understanding document
browsers allow you to zoom - analogous to mobile apps allow you to zoom
bye
<Chris_Loiselle> if someone was to remove ability to zoom (pinch to zoom) then that would fail. I believe around 2017 iOS and Android changed user scalable restrictions