Meeting minutes
<maryjom> Survey results: Closed functionality bullets for SCs 2.1.2, 2.1.4, 2.4.7, 2.5.2, 3.1.1, 3.1.2, 3.2.3 and 4.1.2
<maryjom> Survey results: Closed functionality: Intro and bullets for 1.4.5, 2.4.3, and 4.1.3
Announcements
<bruce_bailey> Updated agenda email: https://
maryjom: Announcement - now doing additional meetings on Fridays to try and develop any new proposals to SCs or answers to public comments
… Then full task force can review output on a Thursday
… Friday meeting starts @ 9am EST, apologies for it being so early for West Coast US
Question from GreggVan on changing timing that surveys are due - unfortunately that is a W3C default, just choose the day
<bruce_bailey> Wiki agenda page for today is also up to date: https://
Chuck: Adding to the survey timings - it has been a long standing issue, there was a request for enhancement to add timings, but not been actioned
GreggVan: CHI & IEEE allow you to pick timezone.
maryjom: Unfortunately we just have to live with the tool - and please complete surveys at least 1 day early (pref. more)
<bruce_bailey> At top of call, the few of us were expressing our appreciation for the work Mary Jo doing to synthesize survey feedback.
maryjom: Did talk at AG WG on 4.1.1 parsing. Still discussion on MathML parsing by screen readers
… Seems odd to require something that you cannot test (after initial development). Discussion is ongoing.
… Hope is to not have to add content, but if we do, GreggVan has proposed content that we could use
GreggVan: It must be a real problem that is being reported
maryjom: and also needs to be testable...
Survey results: Review of proposed responses to public comments
All content for proposals to public comments have been accepted in the survey
<bruce_bailey> Yes, DHS trusted tester never came up with a good tool for 4.1.1, and the Web ICT Testing Baseline is dropping it.
<maryjom> https://
<maryjom> • DRAFT RESOLUTION: Accept the proposed answers to public comments in Issues 5, 6, 77, 229, 261, and 268 as proposed in the survey, without changes.
+1
<loicmn> +1
<bruce_bailey> +1
<olivia> +1
<ThorstenKatzmann> +1
<Mike_Pluke> +1
<GreggVan> +1
<mitch11> +1
<Sam> +1
RESOLUTION: Accept the proposed answers to public comments in Issues 5, 6, 77, 229, 261, and 268 as proposed in the survey, without changes.
<Laura_B_Miller> +1
bruce_bailey: Still seeing links in the source code to 2.1 of understanding, not 2.2
dmontalvo: Will look to see which is coming from content, and which is coming from scripts
maryjom: Will also check content
bruce_bailey to open Editorial issue to check understanding links all link to 2.2 in all instances
… dmontalvo to be added to issue and maryjom
Survey results: Review of updated draft for 3.2.6 Consistent Help
<maryjom> https://
q1, all answered to incorporate as is, so that is approved
<maryjom> DRAFT RESOLUTION: Incorporate the proposal for Applying SC 3.2.6 Consistent Help to Non-Web Documents and Software section as-is.
+1
<loicmn> +1
<bruce_bailey> +1
<Mike_Pluke> +1
<ThorstenKatzmann> +1
<olivia> +1
<Laura_B_Miller> +1
<FernandaBonnin> +1
RESOLUTION: Incorporate the proposal for Applying SC 3.2.6 Consistent Help to Non-Web Documents and Software section as-is.
q2: proposed note
… SC uses sets of web pages so propose an additional note
6 wanted as is, bruce_bailey had editorial to change terminology
maryjom: if we do change here, we will have to do the change in all other places to keep consistent
<maryjom> Poll: Should we rephrase Note 3 to say • DRAFT RESOLUTION: Incorporate the proposal for Applying SC 3.2.6 Consistent Help to Non-Web Documents and Software section as-is.
Proposed change from bruce_bailey: Small editorial: I would rather "collection of software" rather than "pieces of software"
<bruce_bailey> yes, i do not think "pieces of software" is quite correct in context and suggested "collection of software" (similar to defined term)
<maryjom> Poll: Should we rephrase Note 3 to say "collection of software" rather than "pieces of software"
mitch11: Not sure if I agree to make the change - helpful to distinguish between set and pieces of software
<maryjom> Yes or no...
bruce_bailey: Like that we are avoiding set or collection, but pieces sound like portions of code
loicmn: Sentence when a group of documents (or equivalent) ... then would have group of pieces of software which would not work. Prefer to keep as is
GreggVan: Can we not say a group of software programs?
<bruce_bailey> i am content to defer. and keep "pieces of software"
<maryjom> Here's the statement we're talking about...
<maryjom> See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.)
<mitch11> I like "software programs" in this context
<loicmn> +1 to "software programs"
+1 to software programs
<maryjom> Poll: Should we rephrase Note 3 to say "collection of software" rather than "pieces of software"? Yes or no...
<mitch11> no
<FernandaBonnin> no
<loicmn> no
<Mike_Pluke> no
<ThorstenKatzmann> no
<Laura_B_Miller> No
<maryjom> DRAFT RESOLUTION: Incorporate proposed Note 3 for SC 3.2.6 Consistent Help as-is.
<mitch11> +1
<FernandaBonnin> +1
<loicmn> +1
<olivia> +1
+1
<ThorstenKatzmann> +1
<Mike_Pluke> +1
RESOLUTION: Incorporate proposed Note 3 for SC 3.2.6 Consistent Help as-is.
<Sam> +1
<Zakim> Chuck, you wanted to speak after the vote
Chuck: Using term "can live with" causes concern for some, so please use "can accept" or "can tolerate"
Survey results: Closed functionality bullets for SCs 2.1.2, 2.1.4, 2.4.7, 2.5.2, 3.1.1, 3.1.2, 3.2.3 and 4.1.2
<maryjom> https://
Starting with consistent navigation, as we did part of the survey last week. Starting at question 4
Group on Friday looked at this survey and suggested alternate proposals
2 proposals for consistent navigation & consistent identification
Either edit the bullet, or remove
We had previously agreed to include bullets like this for consistency. https://
<maryjom> POLL: Which do you prefer? 1) Remove bullets for SC 3.2.3 and 3.2.4 or 2) Incorporate edited bullets as proposed in the survey.
2
<mitch11> 1
<bruce_bailey> 2
<Sam> 2
<loicmn> 1 (can accept 2)
<olivia> 2
<ThorstenKatzmann> 2
<Mike_Pluke> 2
mitch11: Not sure I see the precedent to include, but happy to concede with majority. Not seeing in the link, but will concede
RESOLUTION: Incorporate bullets for SC 3.2.3 and 3.2.4 into the SC Problematic for Closed Functionality, as-is.
Now onto 4.1.2 Name, Role, Value
5 accept option 2 as is, 2 wanted something else
<maryjom> https://
mitch11: Doesn't have an alternative proposal on this one
maryjom: Looking at last Friday's meeting minutes. Don't want to say "does not apply", think we settled on "the intent of this SC would be met" or something similar
<maryjom> 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Where another mechanism provides equivalent information as built-in assistive technology functionality, the intent of this success criterion would be met.
<Zakim> loicmn, you wanted to propose "the intent of the SC would be met"
loicmn: Happy with what has been proposed - intent of this SC would be met
mitch11: Now remembering a conversation offline with Mary Jo - on drawing bright lines - we do not need to draw bright lines.
… However, option 2 does seem to be a bright line
mitch11: Would prefer to leave it somewhat ambiguous, but if we do want to, then more supportive of the version with intent ... is met
bruce_bailey: Want to note, this is in a different category to 4.1.1 - accessibility need behind 4.1.2 is different. +1 to mitch11
mitch11: Intent of 4.1.2 is to support assistive tech in all its forms. Providing built in AT helps, but may not fully meet the intent
mitch11: Would prefer option 1 over the other 2 options
GreggVan: If you don't meet 4.1.2, then it is a closed product as it does not use AT
All built in AT is only a subset of the AT that is needed
<bruce_bailey> i voted for 2 in survey, but from this discussion, option 1 is better
PhilDay: Would prefer option 3 - it is useful for those designing closed systems to know what is required
<Laura_B_Miller> +1 Sam
Sam: There are other standards - this one is particularly web based, and therefore it may not be possible to meet for some systems. Feel like it might be an over expansion - agree with Phil on option 3
GreggVan: Falls into a category that comes up often - technical impossibility doesn't always mean that it is automatically accessible
<Sam> this is a SC not a requirement that states if the product is "accessible"
maryjom: This is limited to SC problematic for closed functionality. There are a lot of ICT that may not be able to use bolt on AT, but can still meet the intent (e.g. self voice); there is an alternate way of meeting the need
<Zakim> bruce_bailey, you wanted to say 4.1.2 *is* applicable to non web software -- and software with closed functionality should not get a free pass on the intent behind the SC
bruce_bailey: We have 2 categories of SC problematic for closed functionality. This one is the functionality is extremely important - so should be handled differently from some of the others
<Zakim> PhilDay, you wanted to say that we are discussing closed products
<Chuck> +1 on agreement, I think we are...
<Sam> +1 to what Phil is saying
PhilDay: Think we agree on the fundamentals - if you can't bolt on AT, then giving guidance on how to provide alternatives to meet the intent
GreggVan: This is just one of many examples of programmatically determined
<GreggVan> +1 to that
mitch11: In strong agreement that built in AT are better than no AT. But, option 2 still needs rework - "this criterion does not apply" doesn't sound right
<Sam> +1
<maryjom> Option 1: Option 1: Original proposal 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Some other mechanism would be needed to contextually reveal needed information to the user.
mitch11: Not sure which options people are actually wanting. It's not clear what is meant by option 3
<maryjom> Option 2: Incorporate suggested edits 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Where another mechanism provides this information for built-in assistive technology functions, this criterion does not apply.
maryjom: Copying all options in
<bruce_bailey> yes, i agree with @mitch
<maryjom> Option 3: 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Where another mechanism provides equivalent information as built-in assistive technology functionality, the intent of this success criterion would be met.
mitch11: See option 3 in chat, and would still vote for option 1
<GreggVan> Option 4 +1 to say 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. That makes the product closed and this provision would be handled in the same fashion as all other provisions that refer programmatically determinable information
<bruce_bailey> yes, even with option 3 -- i prefer option 1
Laura_B_Miller: Take a step back. Lot of ways we see this implemented in ICT is as a mention in other regulations.
Laura_B_Miller: Are we providing enough of a window for those regs to know what they need to address
… And it feels like that is what we are trying to do.
maryjom: OK, but what do you suggest the bullet should be
… we should be more explicit - look at other regs to know how to test it.
Sam: Understand that we want accessibility in there, but having a requirement that causes more work, and may not overall improve the net accessibility of the product
… Liked option 2, but if that is triggering for some, then prefer option 3. Prefer to not have a requirement that does not work in a closed system.
<maryjom> ak GreggVan
<Zakim> GreggVan, you wanted to say Option 4 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. That makes the product closed and this provision would be handled in the same fashion as all other provisions that refer programmatically determinable information and to say Option 4 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. That makes the product closed and this provision would be handled in the same fashion as all other provisions that refer to programmatically determinable information
GreggVan: I was not saying that you still need to attach AT. Just saying this is the same as the other programmatically determined - so handle in the same way as the other SCs that are similar
<Zakim> bruce_bailey, you wanted to say i don't agree "these are the same"
<GreggVan> +1 to that
bruce_bailey: Think we have multiple categories. Not just programmatically determinable - we have some SCs that also scope to markup language - these would not be applicable. But that's different to programmatically determinable that actually provide accessibility benefit
<Chuck> I must go.
<mitch11> I'd like to see Gregg's (#4) combined with Laura's (See other standards)
maryjom: Will pick this up tomorrow. If you have any input please get in touch
Sam: was invite information sent through email?
maryjom: Was sent from Daniel @ W3C. If you didn't get it, be in touch with maryjom