See also: IRC log
<AWK> +AWK
<AWK> reagent, draft minutes
<AWK> Zaki, ping me us in 62 minutes to get a new scribe
<Mike_Elledge> Welcome back!
<scribe> scribe: bruce_bailey
<scribe> scribe : bruce_bailey
http://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/results#xnew4
Response to comment on 3.2.7 Change of Content #482
<lisa_> the volume is cuting out
This was in response to David MacDonald
AWK: we have the pull request wrt changing second bullet
9 access and others with comments and suggestion
AWK call on Alistair to respond
Alastairc: thinks response covers it
it seems a bit odd that change in focus might exempt
could be 50/50 chance
AWK: similar comments / concerns
it can be a slippery slow with "after" since that could be 10 pages down
does it help? does it hurt?
AWK: we need to think more about user need
calls on Jason
<david-macdonald> monitoring for a few nmoments while on break from teahing
Jason: changes may immediately follow focus might not be where the change is
this is not always the case
example is a form where the content changes as data is put into form
when one selects one field, the fields and options change
user might not know to look
Jason: 2nd point is magnificant does not have to cover all the content that was changed
might just be live area
3rd point was concern that proposal might not be exactly right thing for the user
<Zakim> JF, you wanted to ask about "what kind of notification?" is there a minimum notice required?
conclusion is we should consider more.
John F: To notification issue, do we need to define or clarify?
JF: FaceBook example is just a
ping on a page. Is that enough?
... We kind of envisioned an aria live region, but that might
not be necessary
Jason: We specify something like an aria live region
If we want to allow other approaches, we need to dicuss further
that technology needs to be developed
Users are likely to expect an aria live region
the form example might be a bit missleading
things might not work as well as commenter things.
AWK: to summarize, core of requirement is notification and could be a chime or something
JF: Asks if we have that documented in draft understanding?
MikeG: I was okay with comment, but draft has undefinded terms
<JF> +1 Mike
There are a lot of details and undefined terms that we do not have clear enough
The part about "programatic notification" is okay but not fleshed out enough
AKW: Programmatic notification is made by the author, because of something the author did, but the AT response is not known.
AWK: are there other issues beyond programmatic notification?
MikeG: PN is the main issues but even it is vague.
<jnurthen> +1 to vagueness here
MikeG gives other quick examples of vagues.
Jason: agree significant definitial issues
Thinks we may be able to address those with other current open issues.
HTML5 techniques will cause user agents to be alerted in at least some sense
We should think in our clarifications about how programmatic notification works
AWK: I am hearing some real significant doubts about PN but also this SC in particular.
People like this idea, for a requirement about alerting to changes on the page that does not have immediate focus.
Downstream in the page and sequential reading order are tied into this as well.
In the survey, 9 of us said we should allow the downstream exception
<Zakim> steverep, you wanted to disagree specifically with the exception
Asks for speaking up to agree.
Steve concures with concern. Agrees that exception that exception is a problem.
Steve: Exception assumes that a blind individual only needs to get one read of the page
Steve does not like the change.
AKW asks for reasons to keep the change.
MikeG says that if the change is right after the other control, then it really might not be a problem.
MikeG: If it immediately follows, not something much further down the page, the new information should be readily available.
<Zakim> Brooks, you wanted to ask about intent of SC - Is this about ultimate discoverability of added content, or is this about immediate discoverability of new content?
Brooks: idea is to let user immediately know about new content
Alternative is just that users find out because something is in their way
AKW asks for clarification for concern, back to drop-down example of picking country.
<lisa> just stepping aay for a moment
If user selects US, then drop down is state. If user selects Canada, then drop down is provinces
Brook: Issue is simplier than we might be making. Agrees that user does not need to hear that second group of choices changes.
JohnF: The key issue really seems to be around proximity.
So changing the the very next field change is fine. Most forms and fillout is a linear process.
Question about what happens when going backward? Going back to country field from bottom of form?
How close is close enough?
Jason: Example is survey is similar to what JF described, so picking a different country might delete what the user put into address field.
User would be okay with states changing to providences, and expect that proximate change.
Other changes, like the address line being lost, would need programmatic notification.
If we want to restrict this based on kind of changes, we need some clarification about that.
General assumptions about linear reading order might not hold. So we need to re-evaluation.
James: We need to think more about proximity. If any user makes a choice that changes the (form) page three screens away, no one knows.
JF: Asks about page.
<Alex__> good point
JF clarifies about long page. There are ways to think about proximity and flow.
JF: Flow term is interesting, different than proximity. Is issue really about change of flow?
<lisa> putting my comments n irc.
<lisa> emphasis is also imporant
<lisa> people think you will know or see something becuse it is in bold
If the change is in the experience space of "not yet heard" then changes there are not important.
<lisa> but proximity is not relivent
Shopping cart experience is a good example.
Example with lots of simultaneous data (ex., sports scores) need consideration as well.
MikeG: Context was experience of
screen reader users and aria live and what programmatic
notification could be for different people
... Change of context for the user remains an important
concern.
I reasonable technic is to notify the user.
The user could be notified in advance, but only when the technology does not support the live notification.
Exception for advance notification is too broad as currently written.
MikeG gave the example of the fast keyboard user moving away from focus, missing the screenreader update.
Programmatic notification could have solved that.
Brooks: It is not about options for question 2 changing is not so important as understanding the relation from question 1.
Example of country and then subdivision is okay.
<Zakim> steverep, you wanted to say talking about proximity is a non-starter for me - visual and DOM can be very different
Example of favorite color changing options in next question is must less obvious.
Steve: Talking about proximity is a non-starter since DOM proximity and visual proximity might not be strict enough.
Proximity in terms of cognitive is even more problematic. States coming from country is intuitive.
No end user wants an aria alert about changes down the page when those changes are natural and not needed.
As a full-time screen reader user, I am concerned with current phrasing.
AWK: So we want this funtional and not overly verbose.
Jason: The important changes relevant to the task and how the content is designed.
Change should fall into the scope of what is being effected by the notification.
<JF> There seems to be a distinct dividing line here: forms versus other content that updates (i.e. sport scores, etc.)
So some examples we discussed meet that threshhold
We might also scope this down to UI elements that are added or deleted.
Example of sports results page would be compatible with this, since updates are expected, but not newly added.
<AWK> Current issues logged on "Change of Content" SC: https://github.com/w3c/wcag21/issues?q=is%3Aopen+is%3Aissue+label%3A%7Ecomment-change-of-content
Agree that current phrasing is not sufficient.
AKW: We have a log of significant comments and concerns [as pasted in].
Just one public comment, but it seems we cannot answer it without collectively digesting member concerns.
Looking for volunteer to scrub through issues?
<steverep> +1 to volunteer (fear is a wonderful motivator)
<gowerm> +1
Are there themes? Is is all just different aspects of one issue?
MikeG: Wants to check that COGA group did not initate this?
AKW: Thinks this is of issue to COGA group, but came from mobile task force
<alastairc> This one came from DavidM, one of the few 'misc' SCs.
<lisa> if you want to suggest or cc the coga group that would be fantastic
AKW: Report back in a week? Asking for more time is okay.
RESOLUTION: Leave open. SteveR and MikeG will review and report back.
https://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/results#xnew6
Br
See SteveR:The premise for closing issues like this should be that we must concentrate on 2.1 SC and only talk about 2.0 changes for serious conflicts instead of cosmetics. The group was far from unanimous on making zero changes to 2.0 criteria (and there was no formal decision recorded on it unless I missed it), so there's no need for such a response.
Bruce is okay with respond as ammended
<AWK> "The WG has ruled out changes to WCAG 2.0 SC, in order to maintain clear backwards compatibility. Therefore we will not rename these SC."
AKW has response from Micheal.
Bruce is okay with MC response
<AWK> "The WG has ruled out changes to WCAG 2.0 SC, in order to maintain clear backwards compatibility. Therefore we will not rename these SC for WCAG 2.1 but will defer this issue for future consideration."
<gowerm> +1 "future consideration"
<Ryladog> +1 to AWK
SteveR: Okay. There may be lots of these.
<laura> +1
<KimD> +1
Just because we cannot handle for 2.1, we should not have harsh response.
AKW ask for objections.
MikeG thinks it needs word smithing.
<gowerm> Teh WG has ruled out editorial or substantive changes to WCAG 2.0... compatibility while creating WCAG 2.1. Therefore...
JF: To what SteveR asks. Did we not decide not to change anything in 2.1 that is coming over from 2.0?
We decided to create new SC for 2.1 so we avoided need to edit 2.0 SC.
<gowerm> "The WG has ruled out changes to WCAG 2.0 normative language while updating WCAG 2.1 SC , in order to maintain clear backwards compatibility. Therefore we will not rename these SC for WCAG 2.1 but will defer this issue for future consideration."
MikeCooper: We made decision NOT to change 2.0 SC but reserved option to come back to 2.0 SC.
Not in favor of deciding not to decide, but that is what the WG settled upon.
AWK concurs w/ MC assessment.
<gowerm> "The WG has ruled out changes to WCAG 2.0 normative language while drafting WCAG 2.1 SC , in order to maintain clear backwards compatibility.
<JF> +1 to draft response
<alastairc> +1
<laura> +1
AKW asks for objections.
<Makoto> +1
<gowerm> "The WG has ruled out changes to WCAG 2.0 normative language while drafting WCAG 2.1 SC, in order to maintain clear backwards compatibility. Therefore we will not rename these SC for WCAG 2.1 but will defer this issue for future consideration."
RESOLUTION: accept response as ammended
<JF> From our Charter: The WCAG 2.1 update will be an incremental update to WCAG 2.0 rather than a major revision. WCAG 2.1 is designed to build on the WCAG 2.0 recommendation to ensure testability and technology independence, and will also ensure backward compatibility with WCAG 2.0.
8. Proposed response to Learning Disabilities of America - Technology Committee Comments: WCAG 2.1 For Learning Disabilities and Cognitive Disabilities #211
Lisa S: The response was polite, said what we are doing, but does not address concerns
Commenter suggested changing levels, some AAA they asked to be Single A
We have not explained why we are not making changes
Lisa thinks our response should offer more explaination
characterization of suggested SC not being mature should be more specific
For example, if suggestions are not testable, we should say so
If there are other issues, we should explain more
We do have aspirations to pull more into a road map, so we should explain that
We should explain more why we are not accepting their request now
<gowerm> +1 to Lisa drafting a response for WG review
We know something won't get into 2.2 so we could say that, but say what we are working on
We could also talk about Silver and non-normative supporting documents
JF: As the author of the response, I wanted to keep it short
factual, accurate, concise in response
commenter made on comment for 10 SCs
If they want forensics, the links to research materials is there
<alastairc> I think there is a point to add about why some things won't make A/AA, and one point to make about the other (non SC) means of improvements.
JF disagrees that response is patronizing
<Zakim> MichaelC, you wanted to say difficult to respond substantively to this comment before we have finished other issues affecting those SC
JF: Commenter response is to older draft. Shorter response is better than writting a book.
MC: Seems like the kind of thing where we cannot respond until we have addressed larger issues affecting SCs.
MC agrees with JF observation that comment is on earlier draft.
LisaS: yes, they have taken 10 comments and merged them into 1, but issue could be addressed better.
Commenter deserves more serious response.
If they had asked 10 separate questions, would we not have 10 responses?
Do we have a good explaination why personalization is at AA and not single A?
Commenter is new to WCAG, so they are familar with our process.
Commenter is raising significant issues that deserve more in depth response.
<AWK> AWK: to clarify, they didn't look at the wrong version, the comment is older and based on an earlier version.
JF: The answer to why SC are A and AA is link provided.
Lisa is asking us for more justification, but commenter has not described why they think SC should be at different levels.
<lisa> actulay i am asking us to discuss if they are right and if we can do anything they asked for
<lisa> rather then just explain why not
There are a several SC that we have moved along, and have settled on AA v AAA or A
<lisa> +1 o steve
JF: We have lots of background and a document trail. Response provides that.
Alastair: Understands Lisa's point, but there is too much ground to cover to go over all the history that Lisa is asking for.
<JF> Points to: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria#Initial_Suggestion_for_Priority_Level
Alastair: Ther
There is also the ongoing compromise we have been making all along to balance importance and adoption.
<JF> Current version: https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head
Alastair has started to draft that up.
AWK: Agrees that working out
response via github is challenging when commenters are tracking
the work-in-progress draft proposed response
... Github proposed responses have been good about putting
work-in-progress caveats
but we might want to respond on list too.
LisaS: We had said we might consider changing levels based on feedback towards end.
<AWK> AWK: Think that we should focus on the non-deferred SC in the response and link to the details on the deferred ones
LisaS: So we should send interim responsed. We should ask if commenter can give us more information and documentation supporting their reasoning.
It is true that there some kind of balance, but should solict them for more information regarding the importance of adjusting SC.
LisaS: Especially for a commenter that might not only be new to our process but new to WCAG.
<Zakim> steverep, you wanted to say this can be a dialogue not a final answer
LisaS disagrees with closing the response.
SteveR: Agrees with LisaS, and
that traditional one comment / one response approach might not
be best in this case.
... We could ask "You say this should be A when we said AA.
Why?"
... We should not be so eager to close this out, just leave as
a dialog.
AWK: I agree with SteveR, LisaS, and JF concerns. But it is 10 issues.
AWK maybe use JF response as invitation to open dialog?
AWK: We could still say which are closed, current state of others, and which are defered to Silver.
So we ask to close this issue, then open new issues as needed.
JF: Concurs with proposed approach, but may not to continue to steer this particular response.
<alastairc> I'm afraid I have to drop off now, I've just emailed Lisa and the list with a starting point, if Lisa updates that, I'm happy to put the whole response together.
LisaS: Can we offer someone to followup with with explaination of process and how best to contribute?
Maybe do that by phone?
AWK: Talks with LisaS about proposed followup. Agrees that we have to leave open.
Alastair has volunteered to work on drafting response.
AWK also volunteers to work on response.
RESOLUTION: leave open, AKW and AC will work
AWK: No survey for now
We discussed a couple weeks ago
Remaining issues was accessiblity support documentation
<AWK> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0244.html
AWK and SteveR have discussed and see not to list [above].
Okay with having 5 conforming websites, one at AAA
Two implementations for each new SC
Sufficient Techniques updated in response to comments
We have several new SC for authors doing something, example purpose of controls
Techniques could be title or aria, and is already covered by techniques for 2.0
<lisa> it does not need browser support
There are questions about context that need significant accessiblity support documentation
So that is a couple examples of browsers and AT
Show our work as we say
Jason: Agree with AWK approach as outlined, but some techniques rely on technology that are only readay as we get close to CR
<AWK> AWK: The line in the exit criteria current suggested says 'Accessibility support documentation for SC with platform/user agent/assistive technology dependencies is available for at least two technologies with at least four platforms (operating system/user agent/assistive technology combinations);'
So we need to have some caveats around techniques that coming down to the wire timing wise
AKW: Working group responsible for intepreting that line.
If we do not have consenses, we may have to drop SC near deadline
<Zakim> steverep, you wanted to agree in concept with AWK, but disagree on some SC
Jason: Needs a bit more clarification.
AWK agrees.
SteveR: Might have concern with status of some SC.
When do we have to have techniques for every SC?
Is it before or after SC is met?
AWK: We have to have it before.
SteveR is okay with that.
AKW: This makes things like "purpose of control" to be clear.
AWK: List does not itself have to be in exit criteria.
Brooks: No reason to exclude "purpose of control" and important not to exclude it.
AWK notes that some new SC might turn out to have already written techniques for 2.0.
LisaS: Sufficient technique might just be in the page HTML and just noted.
Lisa requests more guidence, for example if a plug-in needs to work in four browsers.
LisaS is concerned that SC could be dropped just because of misunderstanding about what work needed to go into exit criteria.
AWK clarifies that exit criteria is coming from requirements for CR process.
MC: We need to know what our exit criteria are in order to go to CR.
LisaS: Maybe we have a separate discussion about what we expect to provide?
JF: Yes, we need to have examples of purpose of control, but before that we need at least one technique for each new SC.
<Zakim> AWK, you wanted to say that it isn't enough for the "data" to be in the HTML, there needs to be AT/UA that support it
JF: We need to show that new SC are doable. Lets get away from individual SC and focus on exit criteria.
AWK: The purpose of the accessibility support documentation is to show that users benefit from the work that authors do.
AKW gives example with ALT tags, that the technique is not sufficient if AT does not do something with the ALT tag.
The exit criteria requires demonstration of actual function.
<Zakim> laura, you wanted to ask: Does "Accessibility support documentation is available for at least two technologies" mean that SCs must currently work in 2 technologies such as PDF and
The four platform requirement is somewhat flexible in that multiple OS count.
Laura: How much do we have do
document?
... Do we need multiple technologies for each SC?
<Zakim> MichaelC, you wanted to say implementation doesn´t mean just browser but has to mean *something*
The adapting text SC is an example where we might only have support in HTML
AKW: For WCAG 2.0 we looked at PDF, Silverlight, and other technologies.
MC: For WCAG 2.0, we did not require that every technique be available for PDF.
MC clarifies that the presence of markup only is not enough.
We need an implementation does something useful with some combination of browser + AT.
MC agrees with JF that if cannot write a technique, then that is blocking.
Jason: It is difficult to argue for a requirement that does not help users in actual practice.
As far as adoption is concerned, we really need experience to know that what is in the SC and a technique is what is actually needed.
What we ask for is what is the user needed.
<Zakim> JF, you wanted to ask about dependencies on "AT" - is that a criteria?
Otherwise we would speculating on non-exiting technology.
JF: Ask about ALT tag example, since not every PWD uses AT, but might still be useful.
Another example is schema.org meta data which is tremenously useful and in actual use, but not exposed to AT at the moment.
JF: Autocomplete is an example of something that is tremendously useful, and useful for PWD. Does that pass?
AWK: Alt tag example was just a
nominal example, but if nothing used it, alt tags would not be
suffiicient.
... Some 2.1 SC might not be available to AT because the
browser is not making the data available.
Purpose of control is pretty broad, and our exit criteria does not require that it work everywhere, just that we can demonstrate a couple good examples.
JF: Some of new SC transcend AT, so don't want to be trapped by that.
<Zakim> steverep, you wanted to ask how schema.org is consumed by users?
SteveR: The whole point is that we cannot claim conformance without accessilbilty support.
That requirement is in WCAG 2.0 now.
<Zakim> MichaelC, you wanted to say AT vs user benefit; use impact user interaction modulo a11y metadata conformance bit
If the only AT for purpose of control uses micro data or schema.org, that would not be accessibilty support.
MC: To simplify, we require benefit to user.
<JF> +1 to mcooper
Accessibility support is a bit of misnomber because we actually prefere for the benefit to come from the browser, not AT.
WRT schema.org, we have not extended support to PWD to be outside the direct user experience.
<lisa> so autocomplete, which helps the use, is one technology
<lisa> and a plug in is a second
Katie: If any new SC that gets in under Principle 4 still requires user agent support
AWK: Heads up, expect survey for Understanding
TPAC just a couple weeks away, read the Understanding doc ahead of time!
Please feel free to brainstorm and add new techniques to that wiki
Katie asks JF if dinner date set?
JF working on it, should have date by Friday,
trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/scribe:bruce_bailey/scribe: bruce_bailey/ Succeeded: s/AKW/AWK/ Succeeded: s/provices [sp]/provinces/ Succeeded: s/Jason clarifies/JF clarifies/ Succeeded: s/making changing/making changes/ Default Present: AWK, bruce_bailey, KimD, jasonjgw, Makoto, Laura, Mike_Elledge, MichaelC, lisa, alastairc, MikeGower, Brooks, JF, steverep, Katie_Haritos-Shea, Pietro, kirkwood, david-macdonald WARNING: Replacing previous Present list. (Old list: (no, one), bruce_bailey, KimD, jasonjgw, Makoto) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, bruce_bailey, KimD, jasonjgw, Makoto Present: AWK bruce_bailey KimD jasonjgw Makoto Laura Mike_Elledge MichaelC lisa alastairc MikeGower Brooks JF steverep Katie_Haritos-Shea Pietro kirkwood david-macdonald Regrets: Andy_heath_Kathy_Wahlbin Jake_EA_draffan David_MacDonald Found Scribe: bruce_bailey Inferring ScribeNick: bruce_bailey Found Scribe: bruce_bailey Inferring ScribeNick: bruce_bailey Found Date: 24 Oct 2017 Guessing minutes URL: http://www.w3.org/2017/10/24-ag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]