Meeting minutes
Announcements
maryjom: reminder to please provide input before meeting
… at least a day, as it make review before meeting easier
maryjom: Chris L and I have been doing a lot of work into Editors Draft..
… lost some section titles with reformatting. We want to get this in front of AG WG soon.
… we have background section and other front matter
… final formatting is not in place, but we can link to previous version which we do expect to emulate in form
Any questions?
<maryjom> POLL: Do you support sending the current draft to the AG WG for review provided we have them focus only on sections we’ve updated or added?
<mitch11> no objection
Phil Day: I though motion actuation was in ED ? But not seeing it yet, but I might have missed a step.
maryjom: I though it was in, so I will double check on Motion Actuation
… earliest review is a couple weeks because I want to brief ag chair and there will be survey
… looks like March 14 would be soonest for review during AG call
<Devanshu> +1
<loicmn> +1
<ChrisLoiselle> +1 to showcasing our work :)
daniel-montalvo: Might just be missing brace , i will double check
<olivia-hogan-stark> +1
<ThorstenKatzmann> +1
<maryjom> +1
<BryanTrogdon> +1
+1
<ShawnT> +1
<Sam> +1
maryjom: Straw poll approved, so I will coordinate with Chuck and AG WG co chairs
… we are getting feed back from AGWG members, so that is good.
… TWO surveys for next week, so please read and digest and respond as soon as you can
… content on hover focus, glossary terms, and some AAA sc as well.
… we will continue working even while current material up for AGWG review and survey.
maryjom: Peter Cooper still working on includes , so we will have more complete document to look at.
Project standup (status of your assigned issues)
Mary Jo switches to screen share and project view on GitHub repo.
Olivia moves #35 to "in progress"
correction, issue 32 for olivia
but issues #35 also in progress
Note that Project Board uses drag-and-drop card view but issues status of an issue can also be set from issue view
<mitch11> 1+
Bruce: 2.5.1: will work on issue #31 this coming week
maryjom: I have done some work on definitions and a few other issues
… look for more work for next week with reviews.
mitch11: I have a 2.2 pending issue not yet reviewed , so that will impact status here
… that is proposed changed note for WCAG2ICT issue #22
maryjom: Agree that until 2.2 in TR, there could be some changes for our work
Survey: Review of SC 2.5.3 readiness to incorporate into editor’s draft
maryjom: This is label in name, 8 responses, 2 as-is, 5 with changes, 1 not yet
maryjom: i will summarize and focus on issue thread
maryjom: summarizing suggestions about label in name and accessible name , concurrence in survey
Survey results: https://
Issue #99: w3c/
maryjom: survey noted that this is one SC where programmatically determinable may need to be called out
… similar concept in different technology for accessible name but our note might be too brittle if we are too html specific
maryjom: I have some consolidated comments in issue thread
<maryjom> w3c/
<mitch11> 1+
maryjom: This was an issue with the previous document, if we do not have word substitution, then it makes it harder to notice nuance or interpretation of terms
maryjom: calls on olivia wrt on "not ready" survey response
olivia-hogan-stark: There were a lot of edits in survey and in issue thread -- so it was not clear what specifics we were being asked to agree with
[Mary Jo walks through elements of her consolidation of suggested edits]
Any concerns?
<maryjom> POLL: Do you agree with adding this note to the SC and the bullet to the closed functionality section?
<loicmn> +1
<maryjom> POLL: Do you agree with adding the closed functionality note to the SC and the bullet to the closed functionality section?
<Devanshu> +1
+1
<ThorstenKatzmann> +1
<Sam> +1
<loicmn> +1
<FernandaBonnin> +
<BryanTrogdon> +1
<olivia-hogan-stark> +1
<maryjom> +1
<mitch11> +1
maryjom: Those will be added to our working version
maryjom: reviews comments around calculation for accessible name
<maryjom> https://
above is original text
<maryjom> Suggestion from Mitchell: For non-web documents and software, the accessible name computation depends on object properties in accessibility APIs provided by the platform. "Name" and "AXTitle" are examples of such object properties.
Suggestion from issue thread
Bruce: is AxTitle the actual title?
mitch11: names borrowed from core mapping
… which is W3C doc
mitch11: but I may have miss read . . . as meaning a place holder we could fill.
<Devanshu> +1 to Mitchell's comment
<mitch11> 1-
mitch11: i am not against note , but i a proposing something perhaps more evergreen
maryjom: That does better address my concern that the note might be brittle and become dated over time.
<loicmn> +1 To mitch11 proposal to remove specific examples of "accessible names"
<Sam> +1 to MJ to remove
maryjom: i prefer paraentetical in current wording
<maryjom> +1 to add back the parenthetic (or whatever it is called in different APIs)
<maryjom> https://
<daniel-montalvo> https://
<mitch11> https://
maryjom: We decided NOT to use those, so just a side reference
mitch11: It is about HTML , but HTML running on other platforms. I agree not relevant if we strike from sentence making reference
<maryjom> The user agent or platform software computes the accessible name from object properties set by the non-web document or software and exposes the name to assistive technology via the platform accessibility API.
maryjom: So i think we are okay , as I was taling about technical aspects
… but we might not to get that technial
philday: prefer mitch even proposal (without last sentence)
acj
maryjom: This will need some consideration as how to include parathentical, but that is editoral
mitch11: i think 2013 version is okay, albeit informal "what ever it is called"
<maryjom> Poll: Preference 1) Keep 2013 version as-is 2) Replace with Mitchell's proposal or 3) something else
bruce: 3
<FernandaBonnin> +1 to Bruce suggestion
Bruce: keep it but give some editorial licence to improve on whatever it is called
maryjom: so can we leave to editors ?
Gregg: has an editorial suggestion
… present phrasing read odd because "whatever it is called" is an idiom
GreggVan: change "whatever it is called"with "whatever it is termed"
<mitch11> +1 for this edit
<ChrisLoiselle> suggestion - to the appropriate terminology per applicable API
+1
<loicmn> +1 for term
<olivia-hogan-stark> +1
<maryjom> +1
<ShawnT> +1
<ThorstenKatzmann> +1
<Mike_Pluke> +1
maryjom: any concerns for keeping current with minor editorial?
<GreggVan> +1
maryjom: Editors will copy that phrasing into other places.
daniel-montalvo: or the corresponding term in...
<Mike_Pluke> +1 to "corresponding term"
+1 to corresponding
<maryjom> "or the corresponding term used in different APIs"
<GreggVan> +1
<loicmn> +1
daniel-montalvo: would like to ditch "whatever" but that might be too tricky
all agree that phrasing without using the word "name" is tricky
<maryjom> DRAFT RESOLUTION to incorporate SC 2.5.3 with the changes noted in the minutes: Change to note in the "name" and addition of closed functionality verbiage.
+1
<loicmn> +1
<maryjom> +1
<ThorstenKatzmann> +1
<olivia-hogan-stark> +1
<FernandaBonnin> +1
<Devanshu> +1
<BryanTrogdon> +1
<mitch11> Another concern: the existing note ends with "...is an example of such a name." Yet for future-proofing we prefer not to give any real example
RESOLUTION: Incorporate SC 2.5.3 with the changes noted in the minutes: Change to note in the "name" and addition of closed functionality verbiage.
RESOLUTION: Incorporate SC 2.5.3 with the changes noted in the minutes: Change to note in the "name" and addition of closed functionality verbiage.
maryjom: That is the same editorial fix
<maryjom> “AccessibleName” (or the corresponding term used in different APIs) of the Accessibility API of the platform is an example of such a name.
maryjom: resolution is to keep present phrasing (from 2013) with our editorial improvements as discussed today.
<Zakim> GreggVan, you wanted to say "or whatever the term is in different APIs"
mitch11: okay, no objection
<FernandaBonnin> https://
https://
Discussion thread on applying 1.4.10 Reflow to non-web documents and software
maryjom: Thanks for the robust discussion in the issue thread...
… we need to settle if CSS pixel is a reasonable term to use in WCAG2ICT
philday: I agree with Mitch Evens concern that it is obtuse that the very technical definition works for technolgy that does not use CSS nor even pixels.
maryjom: reviews definition used in WCAG 2.1 -- which is an angle
<maryjom> https://
<maryjom> https://
maryjom: <q>visual angle of about 0.0213 degrees</q>
… reference illlustrates how to measure on other devices
Sam: My hardware colleagues have pointed out that there is a disconnect to the technology...
… not a single pixel, but three, and nowadays there is white backlight
… reference document is not using contempary technologies
mitch11: Agee with Sam's concerns as true -- but WCAG2 definition gets around that because it is just and only the angle...
… there is nothing about the definition which says how many physical pixels are required for each CSS pixel -- so term works as is.
GreggVan: Problem stems from how can content authors be responsible for display size which is unknown?
<mitch11> bruce thank you, you summarized my rambling accurately
GreggVan: but concern is a red herring because definition written to address very concern
… examples are irrelevant and distracting
<FernandaBonnin> I can finish scribing
philday: I agree, but designers are going to look to illustration and try to interpert picture despite definition
Sam: to add on to this mix, the view angle and the view distance, although set for most displays, printers and other devices will be varying.
Sam: to add, the viewing angle and viewing distance is informational, but for things like displays on printers those are not helpful
… there are other standard which site specific text size...
<Zakim> loicmn, you wanted to say that "CSS pixel" current definition (based on "angle") is the only way to go (we used the same approach in EN 301 549).
Sam: other requirements agbout text and viewing angle will make this even more difficult. This is adding more complexity and shoe horning CSS pixels makes it difficult
… using CSS pixel here seems very problematic
loicmn: there is no other way , and we wrestle with this so much ...
… we might use "eye pixel" alternative like fixed measures are going to be worse
<mitch11> I agree with Loic, viewing angle works, but the word "CSS" in "CSS pixel" causes confusion
loicmn: reference mentions viewing distance to work back from (28 in or 71 cm) no better alternative in all these years hence
philday: we are losing people, cannot close
maryjom: Agreed , we will keep discussing
… wanted to start today because it will not be a quick conversation
I do agree with Loic & mitch that the word "CSS" is unhelpful in CSS pixels
<Zakim> GreggVan, you wanted to suggest applies as written except change CSS Pixel to "xxx angle of view (equiv to 1 CSS pixel)" and ignore all references go phydical pixels