Meeting minutes
Zakim , take up next
Announcements
MaryJo: AG working group is onboard with us republishing WCAG2ICT once we've covered our issues and incorporated our changes.
… We also did some editorial text updates.
… editors to go through entire note to update edits on formatting , for example bold , not bold type updats.
Bruce: No new version, just new date?
MaryJo: Just republish and syncing with EN.
MaryJo: We don't version. It is just an issue of note date.
PR proprosal approvals
Issue 704: 1.4.4 Resize Text: EN 301 549 did not incorporate our updated notes
<maryjom> Link to issue 704: w3c/
<maryjom> Link to MATF research regarding mobile text resizing: w3c/
MaryJo: Provides link to mobile task force too, as there were mobile issues opened on this topic.
… some operating systems like iOS , like headings, don't scale at 200 percent. It is somewhat less.
… headings become less usable on small devices. I believe that is why we came up with alternative language
… MaryJo talks to 2024 WCAG2ICT current note vs. 2013 note.
Note 2 on WCAG2ICT talks to user settings in platform.
EN thought that was introducing exception that wasn't in WCAG and kept notes from 2013.
MaryJo: Lets keep the conversation on non web software first.
<Zakim> bbailey, you wanted to ask if MATF still work in progress -- but do they have proposed replacement language for 1.4.4 ?
Bruce: MATF is working but have they looked at 1.4.4 too?
MaryJo: I think it is as conversation level.
https://
They are talking to it per the above issues in their repo as of June 18th
<bbailey> See column three at w3c/
<maryjom> Link to WCAG2Mobile: https://
Gregg: Do you have the link?
<bbailey> Column 3 second table parenthetical
<maryjom> Link to the MATF issue 3 on 1.4.4: w3c/
MaryJo: Yes, research link is provided on read issue 3 on their current note for 1.4.4
Gregg: Mobile Task force seems to be part of ICT. It makes it hard as EN covers mobile.
On the 2024 note, it reads that if it doesn't support, you don't have to do anything. If OS doesn't provide it, you don't have to do anything.
<maryjom> Note 2 (Added): For non-web software, there may be cases where the platform provides zoom features, but it does not scale all text up to 200%. In such cases, authors are encouraged to meet user needs by scaling text to the extent supported by user settings in the platform.
<bbailey> iOS -- widely regarded as perfectly satisfactory on this accessibility detail -- only does 153% for "large title" AND THAT IS FINE
MaryJo: I pasted in a proposed text.
Gregg: We can't suggest WCAG make changes but we can say when in non-web do something different.
Gregg: reads as scaling text only as much as the OS does it for you. Still reads as not required to do anything. Provision talks to loss of functionality, correct?
It needs to say it needs to be different , but not in a note, as it is an exception.
should read as doesn't apply as written, then state why without that why being in a note.
<bbailey> https://
<bbailey> Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
state need to support without loss of functionality aspect and when you zoom it doesn't destroy content.
Gregg: Content doesn't break when zoomed is what you are after. Original SC was on 200 percent as all browsers supported it.
<Zakim> bbailey, you wanted to say that is too much of a loop hole
Bruce: If the platform doesn't provide anything , it is a pass. It didn't seem strong enough to me.
<maryjom> Normative language would be better as: Except for captions and images of text, text can be resized without assistive technology up to 200 percent or supports the platform-supplied text resizing capabilities up to 200 percent without loss of content or functionality.
Gregg: You can change it when it doesn't apply to web content.
Gregg: If I have a document that is on the web, then take it off the web and vice versa, you'd need to follow appropriate steps.
Mike: I don't think we have a comment like that.
Gregg: We try to follow WCAG when we can.
MaryJo: On closed system, there is something.
<bbailey> Proposed: NOTE 2: For non-web software, there may be cases where the platform does not scale all text up to 200% @@but does provide a zoom feature@@. In such cases, authors are encouraged to meet user needs by scaling text to the extent supported by user settings in the platform.
Bruce: I pasted MaryJo's proposed note 2 and added words.
MaryJo: I did talk to normative change in IRC.
Mike: We have one requirement and it is different on closed vs. not closed.
MaryJo: for normative change, wordsmiths in Google doc.
Gregg: The normative change doesn't have if platform doesn't have capability to resize. I think the wording should be or , if the platform provides...
<bbailey> 1 of 2) doesn't require minimal features of platform
<bbailey> 2 of 2) probably we should have exception for closed when size is .25 inch (or whatever)
<maryjom> Link to google doc
<maryjom> https://
<Zakim> bbailey, you wanted to say 2 problems
Bruce: I think this is similar to what we have in 508. If we allow platform features, then we have expectations on those platforms.
Bruce: We don't want to failing iOS when iOS is doing well.
Gregg: Text size vs. zooming is different. You want to cover the reflow , etc.
Mike: no other comment.
<bbailey> 3of2) wouldn't want iOS current feature set to be a fail
Gregg: Wordsmiths on the 1.4.4 text resizing language.
group continues to wordsmith on Google Doc.
Gregg: Do we have text resizing on platforms, Mike?
Mike: I don't believe so.
MaryJo: I believe the text in Google doc provides relief to mobile per what we have here.
Gregg: This meets original intent on WCAG on the not breaking when zooming to 200 percent.
MaryJo: We'd want to split out documents vs. non-web software.
Gregg: Documents shouldn't have to add code.
Gregg: talks to dialog boxes being laid out dynamically.
MaryJo: It may be more of an issue in web content.
Gregg: Mike?
Mike: Looks good , to capturing essentials.
Gregg: this would be an actual change and not a note.
Gregg: This would be a different provision for non-web software.
MaryJo: Suggested normative change for non-web software alone and documents?
Gregg: More important for documents.
MaryJo: I will provide link to table in work for week https://
Issue 612 - 2.5.7 Dragging Movements - "underlying platform software" vs "user agent or platform software
<maryjom> Link to issue 612: w3c/
<GreggVan> +1
<maryjom> Link to comment with instances of “underlying platform software”: w3c/
MaryJo: we made adjustments to the bolding.
<maryjom> Link to PR 734: w3c/
MaryJo: Shows changes , example shown is 1.4.11 user agent and platform software are bolded vs. not bold.
<maryjom> DRAFT RESOLUTION: Incorporate PR 734, making use of "underlying platform software" and "user agent or other platform software" consistent throughout
<GreggVan> +1
<ChrisLoiselle> +1
<Mike_Pluke> +1
<bbailey> +1
Gregg: Will you send Mike a list of the edits?
RESOLUTION: Incorporate PR 734, making use of "underlying platform software" and "user agent or other platform software" consistent throughout
MaryJo: Yes, once it is done. Past PRs gathering is happening.
Issue 740: 2.1.1 Keyboard - Should we add a precondition scoping this SC?
<maryjom> Link to issue 740: w3c/
<maryjom> Link to PR 741: w3c/
Gregg: Even without a formal draft, while we are editing, we can talk to each other to make sure we are all aware of same items.
MaryJo: On notes update to 2.1.1 keyboard, we were talking about a pre-condition
… various proposals provided in PR
Gregg: 1, 2 and 3 are out.
ChrisLoiselle: I support 4
<bbailey> I support option 4
Mike: If we go with option 3, we may need a note on what would come under device independent keyboard interface.
Mike: I support 4
MaryJo: Note too on device-independent ?
Mike: On screen vs. not , concept of device-independent keyboard interface may benefit understanding of what we mean.
<maryjom> DRAFT RESOLUTION: For 2.1.1 Keyboard, incorporate Proposal 4 into the editor's draft, as-is
Mike: proposal 4 is fine.
Bruce: same as a kiosk to information ?
Bruce: I wouldn't want to support the easy approach vs. on screen keyboard.
Gregg: I think a discussion offline is worth it. We'd have to write that in to closed product specficiation.
MaryJo: I believe there are notes on this in closed functionality.
<maryjom> DRAFT RESOLUTION: For 2.1.1 Keyboard, incorporate Proposal 4 into the editor's draft, as-is
<bbailey> +1
<ChrisLoiselle> +1 to proposal 4
<Mike_Pluke> +1
<GreggVan> NOTE: "a device-independent keyboard interface service, " refers to the platform service that provides keystrokes to any software running on the platform. Inclusion of an on-screen keyboard can be done as well but does not meet this since it does not allow for the use of keyboard alternatives.
RESOLUTION: For 2.1.1 Keyboard, incorporate Proposal 4 into the editor's draft, as-is
<GreggVan> NOTE: "a device-independent keyboard interface service, " refers to the platform service that provides keystrokes to any software running on the platform. Inclusion of an on-screen keyboard can be done as well but does not meet this requirement since it does not allow for the use of keyboard alternatives.
MaryJo: We will cover the note next week
will continue 1.4.4 dicussion
will continue issue 736 as well.
splitting that note in to two distinct would be worthwhile