Meeting minutes
maryjom: Welcome folks to first of our earlier meeting times.
Maryjo: We don't quite have agenda, so may run like a Friday call.
Announcements
bruce: see https://
… updates 504, references 2.1 not 2.2
Maryjo: Friday meetings will continue. Thanks to Phil for pointing out update on issues and with creating PRs....
… be on the lookout for survey. Bruce also has a PR in queue.
maryjom: We will continue plugging through content. Also look for 4.1.1 update soon...
<Zakim> bruce_bailey, you wanted to mention HHS reg
maryjom: Any changes we make for 1.4.1 resize text next need a little more editing
LauraMiller: HHS rule also address kiosks, medical devices, and mobile.
… of coures, WCAG does not work well for hardward.
Bruce: This is a rule.
… was out for public comment months and months ago.
LauraMiller: Was about when USAB SSTM ANPRM came out.
LauraMiller: There was an announment last week with PDF version.
<LauraMiller> https://
mitch11: WRT surveys, we have gotten used to very granular. I know I would prefers fewer questions when most of survey is editorial.
… to clarity, i would prefer reserving surveys for technical issues.
maryjom: Survey are better for multiple options. PR is not a good mechnism for offering choices.
<LauraMiller> @Maryjom this is the link to the comments made: https://
maryjom: PRs which are purely editiorial, editors will go forward with those. The surveys are better when editors needed to decide between two or more phrasings.
maryjom: We have enough people here early, thank you, that will proceed as usual.
Survey results: Issue 4
<maryjom> Link to survey: https://
Question (1 of 4) Point 3: SC 1.4.4 should require scaling to the extent supported by user settings of the platform
maryjom: The Issue 4 survey, see link, and I will set topics.
<maryjom> Link to results for question 1: https://
maryjom: A good bit to dig through here, we will work from Google doc.
<maryjom> Google doc: https://
maryjom: I will provide links to correct heading in doc for each topic.
<maryjom> Point 3 in google doc: https://
Survey result spit, 3 as-is and 3 with edit (and one comment in "something else" camp.
Phil, Chris, Bruce -- okay as is.
<maryjom> Sam's proposal 3 link: https://
Sam proposed an option 3, loic endsored Sam's proposal.
A bit longer note now, and Sam added not that, for multiple displays, only one needs to met.
Fernanda noted (in survey) that edit seems like a significant departure from WCAG.
maryjom: It is not clear Fernanda saw Sam's proposal.
Chuck: Response critiques existing WCAG guidance, so I don't think we should go there.
<Chuck> s /we should go there/we should not go there/
maryjom: Agree with not touching WCAG, 2013 wcag2ict had someing for 1.4.4 resize text and we have not revisited that previous guidence until now.
<PhilDay> Text from SC problematic for 1.4.4 in current editor's draft is as follows:
<PhilDay> 1.4.4 Resize Text—because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.4 in a closed environment may place a much heavier burden on the content author;
maryjom: 2013 wcag2ict has stood the text of time, so we do not want to undermine anything.
… but are trying to be responsive to questions and issues raised with our rewrite.
Mitch asks for clarification on which survey question we are working on?
maryjom: Previously, we had options and responses (was on option 4 and 5) and we will come back to those.
mitch11: That helps, links in survey are not quite aligned.
<maryjom> https://
<mitch11> I think this is the correct link for the current TOPIC: https://
maryjom: First item is survey is NOT a question but an introduction. For today, we are using numbered options as part of survey question titles.
mitch11t: The slipery slope I have concern for is that 1.4.4 is the only SC which include "without the use of AT" so that is an outlier.
<maryjom> POLL 1: For the original proposal, which proposed response do you prefer for Point 3: 1) Option 2, 2) Option 3, or 3) Something else
maryjom: Option 3 is sams edits.
<olivia> 3
<PhilDay> 3, then 2
<PhilDay> 2 (option 3), then 1 (option 2)
<olivia> 2
<mitch11> 3 (something else): based on option 3
<mitch11> but with a further edit
maryjom: option 3 is choice 2 in the poll
mitch11: One more look please...
<LauraMiller> 2
mitch11: Can we phrase in a way that encourages resize even if does not meet 1.4.4? Meeting intent should be okay.
<PhilDay> helping to meet the user need...
mitch11: want to says "its a good idea" even if not meeting SC literally
Chuck: I suggested phrasing in the possitive, to encourage people to do something -- even if still technially a failure
maryjom: There are already standards for non-web software which say to work with platform setting...
… that might not go to %200, but nowadays mostly does.
<mitch11> Proposed: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to scale content to the extent supported by user settings in the platform.
BruceÑ Are we loosing "intent"?
<Chuck> mitch: I purposefully removed "intent" so we could avoid a judgment on whether or not we meet the criterion.
<Chuck> mitch: It reminds me that we need to meet the user needs rather than the criteria.
<Chuck> +1 to mitch's proposal
<PhilDay> User need edit: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to scale content to the extent supported by user settings in the platform in order to meet the user needs addressed by this success criterion.
<Chuck> Proposed: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to scale content to the extent supported by user settings in the platform.
<mitch11> Proposed and revised: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged meet user needs by scaling content to the extent supported by user settings in the platform.
<Chuck> +1 to newest typed proposal.
<PhilDay> Tweak to Mitch's revised version: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to meet user needs by scaling content to the extent supported by user settings in the platform.
maryjom: Reminder: This is NOT change to document, just what we are putting in an issues response reply
<PhilDay> Original version (intent): For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, scaling content to the extent supported by user settings in the platform is the best approach for meeting the intent of this success criterion.
<PhilDay> Mitch original: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to scale content to the extent supported by user settings in the platform.
<maryjom> Poll: Can you accept the proposed revisions (from Sam and Mitch) to the Issue 4 response? 1) Yes, as-is, 2) Yes, with edits, 3) No...make your suggestion.
<PhilDay> Mitch revised (user needs): For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to meet user needs by scaling content to the extent supported by user settings in the platform.
<PhilDay> 2
<PhilDay> Sorry, I meant 1
<mitch11> 1
<olivia> 1
<LauraMiller> 1
Maryjo: We will do any resolutions after survey.
Maryjo: Moving on in survey, points 4 and 5
… link is to google doc where these are, but most comments were about moving points 4 and 5
<PhilDay> brb
<maryjom> Question 2 of 4 reviewing this content: https://
Maryjo: 6 sufficient, sam voted something else as he had question about Point 5. We've addressed that.
<PhilDay> back
maryjom: Fernanda asked if we should reference ADA or 20/70 or 20/80 referenced in CSS pixel equivalent discussion.
[screen share and accept minor edits in doc for clarity during call]
Chuck: Reminder of context, this is comment / response. We are not drafting changes at this point.
<Chuck> +1 Phil's edits
maryjom: Correct, after we are happy with responses to commenters, we will have an opportunity to revisit text.
<maryjom> POLL: For the “Addition to proposals” content that was moved up from points 4 & 5, which version of that text should be included in the response to Point 3? 1) Option 1, 2) Option 2 – Phil’s edit, or 3) neither, or 4) something else.
<PhilDay> 2
<olivia> 2
<mitch11> 4...
<PhilDay> Addition to proposals: Option 1: Potential additional content for the response
<PhilDay> Where a platform does not support text enlargement up to 200%, non-web software content that has large text (such as content that, in its native size, the height of letter h is greater than 0.25 inches (6.35 millimeters)) would address the user need behind this success criterion.
<PhilDay> Where a non-web software does not allow measurement of physical size, the non-web software should support scaling of 200% above a typical platform default size for body text, and anything smaller than body text.
<PhilDay> Addition to proposals: Option 2: Phil edit
<PhilDay> Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would address the user need behind this success criterion. (Examples are given of what this minimum text size could be in Section 508, clause 402.4 or ADA 2010 standard, clause 707.7.2.)
<PhilDay> Where a non-web software program does not allow measurement of physical size, the non-web software should support scaling of 200%.
mitch11: I think for response we should be less specific, and just mention other standards to meet users needs...
… Response sounds like testable criteria (size of letter h) but we are not planning to have that detail in WCAG2ICT.
<Zakim> Chuck, you wanted to ask for scribe change
<PhilDay> Option 3: Mitch more generic
<PhilDay> Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would address the user need behind this success criterion.
<PhilDay> Where a non-web software program does not allow measurement of physical size, the non-web software should support scaling of 200%.
Phill: I've put a suggestion to Mitch's edit
Mitch: I think the last option doesn't sound quite right. The question is what to do if it doesn't support 200
… We are responding to a situation where it does not reach 200
MJ: I think we are referring to a case where it's not possible to reach 200
<PhilDay> Option 3: Mitch more generic
<PhilDay> Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would also address the user need behind this success criterion.
MJ: Any concerns with removing the sentence as Mitch describe?
<Chuck> Daniel: The proposal is in the google doc?
<Chuck> MaryJo: Yes
<maryjom> POLL: Which do you prefer for the "Addition to proposals” content? 1) Option 1 - original text, 2) Option 2-Phil's edit, 3) Option 3 - mitch's suggestion, or 4) something else?
<PhilDay> 2, then 3
<PhilDay> (Meaning I would accept 3, but prefer 2, not that we should include both!)
<olivia> 2, happy with 3 as well
<ChrisLoiselle> 2, then 3 for me too
<mitch11> 3, or 2 removing the last sentence
<Mike_Pluke> 2
<FernandaBonnin> 3, or 2 without last sentence
<LauraMiller> 2
<Chuck> 2 has the consensus
<PhilDay> Option 2b: Phil edit (with last sentence removed)
<PhilDay> Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would address the user need behind this success criterion. (Examples are given of what this minimum text size could be in Section 508, clause 402.4 or ADA 2010 standard, clause 707.7.2.)
MJ: 2 has that last sentence. Question is having paragraph 1 with more details about these examples of other standards that provide these criteria
… Is it agreeable?
<maryjom> POLL: Is it acceptable to include option 2, removing the last sentence? 1) Yes or 2) No
<mitch11> 1
<FernandaBonnin> 1
<Sam> 1
<PhilDay> 1
<olivia> 1
<LauraMiller> 1
<ChrisLoiselle> uno
MJ: I think we reached consensus
<Mike_Pluke> 1
<maryjom> DRAFT RESOLUTION: Use option 3, as edited with the “Addition to proposals” option 2B as the response to Point 3 in Issue 4.
Mitch: We agreed on some changes to Option 3. I deleted the previous version.
<ChrisLoiselle> 2b to or not 2b that is the question :)
<PhilDay> Option 3: (latest edited version from Google Doc) Take pertinent text from understanding and expand to non-web (Sam edits)
<PhilDay> When known by the authors that a Where the user agent or platform does not provide a text enlargement function, authors would need to provide it. The normative requirement of 1.4.4 has no exemption for inadequate user agent support, and (Understanding SC 1.4.4) clarifies this. It says, "The scaling of content is primarily a user agent
<PhilDay> responsibility," but also, "If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent."
<PhilDay> To expand the understanding’s content to a non-web context:
<PhilDay> "For non-web documents, the scaling of content is primarily a user agent responsibility [and for non-web software, scaling of content is primarily a platform responsibility]. If the author is using a technology whose user agents or platform software do not provide zoom support, the author is responsible to provide this type of functionality
<PhilDay> directly or to provide content that works with the type of functionality provided by the user agent [or platform software]."
<PhilDay> For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to meet user needs by scaling content to the extent supported by user settings in the platform.
<PhilDay> Where the same information is conveyed on multiple displays only one display needs to meet this SC.
<maryjom> DRAFT RESOLUTION: Use option 3, as edited in the Google doc with the “Addition to proposals” option 2B (in IRC above) as the response to Point 3 in Issue 4.
+1
<Sam> +1
<mitch11> +1
<LauraMiller> +1
<ChrisLoiselle> +1
<Mike_Pluke> +1
<PhilDay> +1
RESOLUTION: Use option 3, as edited in the Google doc with the “Addition to proposals” option 2B (in IRC above) as the response to Point 3 in Issue 4.
Question (2 of 4) Points 4 & 5: Parts or all of the text is a sufficient size
MJ: Thanks everybody. This is really good, and we are getting there
<maryjom> Point 5: We should allow most or all text to enlarge to less than 200%, when the text is initially not particularly small\
<PhilDay> Point 4: We should allow large text to enlarge to less than 200%.
MJ: Mitch proposed two options. We haven't surveyed these yet. I think we should talk about them now.
Mitch: I would delete the obsolete ones at this point. Option 2.3 should be a separate option
… I would concentrate on point 4, point 5 we already addressed
MJ: Agree.
… For point 4 we have these two suggestions. Has everyone had a chance to read through these?
<maryjom> POLL: Which response to Point 4 do you prefer? 1) Option 1, 2) Option 2, or 3) Something else.
<mitch11> 2, then 1
<PhilDay> Option 1: Mitch’s 1st try
<PhilDay> We’ve heard from the community, including members of the Low Vision Task Force, that in some contexts it can be better for users to enlarge already-large text to less than 200% of its starting size. For example, current guidance from both Google and Apple for app designers advises that as user settings double the size of body text in apps,
<PhilDay> heading text be increased to a size larger than body text but less than doubled. Such an approach would not meet SC 1.4.4, which is clear in its requirement that text can be resized to 200%. Policies outside of WCAG may allow meeting user needs in ways that do not meet the technical standards, e.g. through "equivalent facilitation".
<PhilDay> Option 2: Mitch’s 2nd try
<PhilDay> While use cases are common on iOS and Android, this same concern also arises in web content, so we defer to #1671 to address these aspects of the current issue.
<PhilDay> 1, but also happy with 2
<bruce_bailey> 2 also happy w 1
<olivia> 1
<Sam> 1
<Mike_Pluke> 1
<ChrisLoiselle> 1 then 2
<LauraMiller> 1
MJ: Seems the more explanatory is the preference. But since everyone is happy with the other as well, do we need any edits?
Phill: I'm not sure if the reference #1671. Is this a Google docs versioning error?
Chuck: I just pulled it up and it's correct.
Mitch: That's a WCAG issue number
MJ: Option one does not include a link to that issue
RESOLUTION: Use Option 1 as the response to points 4 & 5 in the issue, as-is.
Question (3 of 4 on 1.4.4 Text Resizing) Are built-in platform accessibility features considered AT?
<maryjom> https://
<maryjom> Link to google doc Point 6 which has 2 responses in the review: https://
<maryjom> Here’s the WCAG text for 1.4.4: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
MJ: I do want to include the WCAG text for 1.4.4 so that we have it in front of us for reference
<Chuck> +1 we can't do that.
Sam: Based on my comment, does that language need to be there when applied to the rest of IT?
<PhilDay> Option 3: (latest edited version from Google Doc) Take pertinent text from understanding and expand to non-web (Sam edits) - this was originally Point 4 option 1.
<PhilDay> When known by the authors that a user agent or platform does not provide a text enlargement function, authors would need to provide it. The normative requirement of 1.4.4 has no exemption for inadequate user agent support, and (Understanding SC 1.4.4) clarifies this. It says, "The scaling of content is primarily a user agent responsibility," but
<PhilDay> also, "If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent."
<PhilDay> To expand the understanding’s content to a non-web context:
<PhilDay> "For non-web documents, the scaling of content is primarily a user agent responsibility [and for non-web software, scaling of content is primarily a platform responsibility]. If the author is using a technology whose user agents or platform software do not provide zoom support, the author is responsible to provide this type of functionality
<PhilDay> directly or to provide content that works with the type of functionality provided by the user agent [or platform software]."
<PhilDay> For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to meet user needs by scaling content to the extent supported by user settings in the platform.
<PhilDay> Where the same information is conveyed on multiple displays only one display needs to meet this SC.
Sam: By removing the part, it gives so much power for authors, platforms, and others to meet the requirement
… Also, ICT is much broader than just the web domain
<Zakim> bruce_bailey, you wanted to offer perspective on why "without AT" is in SC
Bruce: If we can drop the "without AT" that would be fine for WCAG2ICT. It would not have been good for WCAG as we might never have gotten universal browser zoom
Chuck: I don't think our remit allows us to define what is AT
… I am supportive of point 1 as it is inferred from the supporting documents, in the form of a sufficient technique
<ChrisLoiselle> +1 to Chuck. Is browser zoom an AT in of itself or built in accessibility feature of the browser.
<bruce_bailey> https://
Chuck: That's G142. It allows from non-author provided support from user agents
… In this case, by inference, we don't have to counter WCAG
Fernanda: Some magnifiers just change viewport, not text rendering
Sam: Sometimes accessibility settings are placed in different areas, causing more harm than benefit
Mitch: I tihnk there is a huge benefit for user not to use "traditional magnifiers"
… On software, I think it is hard to achieve
… If the community follows what we say, that could make a great different to users
… To Chuck's point, the question is not whether features are part of the platform, but which part of the platform they belong to
<bruce_bailey> https://
<bruce_bailey> hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents
MJ: If built-in platform accessibility features are considered AT, that means you could not use some of the most well-known mobile OS accessibility features to meet this
… Capturing the screen, and potentially causing things to be pixelated does not sound like the best option
… For example, at the bottom of mobile apps there are panes, you could put your finger on each of them and they will expand
… You want for these to be able to pass
Sam: I think of devices like printers, where's text enlargement. If it's in general settings, that's a mainstream. IF it's in accessibility settings, then is it AT?
<bruce_bailey> Definition from Tech Act: The term “assistive technology device” means any item, piece of equipment, or product system, whether acquired commercially off the shelf, modified, or customized, that is used to increase, maintain, or improve functional capabilities of a child with a disability.
<Zakim> bruce_bailey, you wanted to say accessibility settings is not the same as "assistive technology"
Sam: I find it difficult to ask people to put settings in the right place or call things the right way, in terms of readability
<Chuck> +1 to Bruce
Bruce: I think we don't need to decide when a feature becomes AT and when it does not
<Zakim> ChrisLoiselle, you wanted to raise an issue with AGWG to expand definition of AT with applicable examples that include but are not limited to a list of OS and user agent accessibility settings?
Chris: For me whether it's a feature in the settings area or not it doesn't matter as much. This is more an issue with AG to somewhat expand or qualify that definition
<maryjom> For the purposes of the “without assistive technology” requirement in 1.4.4, built-in platform accessibility **settings** are not considered assistive technology.
Phill: What if wwe completely ignore the mention of assistive technologies and, instead, we pull out the key differences?
… For example, magnifiers versus mechanisms to manipulate text size
<bruce_bailey> "settings" is more specific than "features" but "settings" works fine in context
Mitch: I like that suggestion
… I just wanted to acknowledge that by the time this was written, choices were significantly less
Sam: Could we take Phill's comment that when magnifiers are used that don't make things fuzzy you would be meeting the SC?
MJ: I think we are going to have to work on what the text would look like in tomorrow's meeting
MJ: Next survey question is whether there is need for changes in 1.4.4 or guidance is sufficient as-is. I think we are going to have to discuss tomorrow
<maryjom> Topic for tomorrow: Work on...https://
Survey results: Follow-up survey addressing public comments, SOTD
<maryjom> https://
MJ: Let's jump to #5
Review: Proposed updates to Status of this Document
<maryjom> https://
<maryjom> PR: https://
<maryjom> In context of the document: https://
MJ: Everybody says they are OK with the text as-is
<maryjom> DRAFT RESOLUTION: Accept the proposed edits to the SOTD in PR 344, as-is.
<Sam> +1
<PhilDay> +1
<mitch11> +1
<bruce_bailey> +1
<Mike_Pluke> +1
<olivia> +1
RESOLUTION: Accept the proposed edits to the SOTD in PR 344, as-is.
<ChrisLoiselle> +1
<ChrisLoiselle> I had a plus 6
MJ: Let's go to issue 226. These are answers to the issue, not meant to go into the document
Proposed answer to Issue 226
<maryjom> https://
<maryjom> Content we were reviewing: https://
MJ: Let's go to the Google doc to see proposed edits
<PhilDay> +1
<Sam> +1
<maryjom> DRAFT RESOLUTION: Respond to Issue 226 using the proposed Option 2, with Bruce's and Olivia's edits shown in the Google doc.
<mitch11> +1
<PhilDay> +1
<Sam> +1
<bruce_bailey> +1
<olivia> +1
RESOLUTION: Respond to Issue 226 using the proposed Option 2, with Bruce's and Olivia's edits shown in the Google doc.
<LauraMiller> +1
Proposed answer to Issue 257
<maryjom> https://
<maryjom> Proposed answer: https://
MJ: Chris wonders if we should add the versions or mention the date this aws written. Olivia agrees
Olivi: I'm fine s long as the date is cleaar
Fernanda: I'm ok not adding the version, the date clarifies
… There are iOS and Android devices that will meet that resolution, but for certain devices you won't be able to meet that resolution
MJ: When we made changes to revflow we discussed this. We'll have to double check that, especially notes 6 and 7 on the Editor's Draft
<ChrisLoiselle> need to leave for another call, feel free to push forward without exact versions, I don't object