Meeting minutes
Alastair: giving a few minutes for more arrivals, we'll start soon.
Alastair: Welcome attendees!
Alastair: Hoping for 10 for a quorum to start.
Alastair: WCAG-athon!
Chuck: Recommend we start with the participants we currently have.
Dragging https://www.w3.org/2002/09/wbs/35422/WCAG22-Dragging-movements/results
Alastair: Dragging was one we started last meeting, didn't get too far.
Dragging Movements needs some attention #1917
Alastair: Starting with question 2.
<alastairc> https://
Alastair: Issue 1917 from MG.
Alastair: We merged PR, as it did improve things, but there are other aspects to MG's feedback.
Alastair: Share screen for those who can perceive, and I'll verbalize.
Alastair: Want to start with some of the basis for the guideline in general.
Alastair: We discussed in WCAG 2.1, for which we got pointer gestures in, it seemed like a logical extension. If gestures are an issue, dragging will be an issue.
Alastair: This came back for 2.2. A couple of things that made me pause while reviewing thread, comment on user agents or assistive devices. Click-lock...
Alastair: And whether it's a better solution than we would be asking of authors. Drag-and-drop, and implement buttons on side to move things up and down, or arrow access.
Alastair: Are the solutions we are asking from authors no better than solutions provided by AT? That's where we got to.
Alastair: Detlev has done lots of work on this, and has done some research. Please correct me, it didn't seem that applicable.
Alastair: ...to what the sc is trying to achieve. I want to start with open question: Is this is something we should tackle or put on hold and look through more evidence?
detlev: Not wedded to this. It's a fair question. I haven't been able to find things to substantiate the need. May be out there, but I haven't found such research. I could live with shelving.
detlev: I can do more work if group desires, but not sure if the rest of the group wants to go ahead with this. We aren't sure if this meets a need, and if we want to impose this.
mbgower: I'm not campaigning to drop this, just want to have the conversation. Applies to pointer gestures we have in place.
mbgower: There is no way to... the only way I know of to scroll a page by pointer is to use finger and drag. If you take that as a starting point, if I can't do that...
mbgower: We don't provide a solution to that. That's where I think the first warning sign comes from. I completely understand that some people will have challenges dragging and directional gestures.
mbgower: where is the responsibility line for the author? I know that there are solutions that can be provided by authors. We need research to guide us.
mbgower: I haven't seen studies. Here we get into dragging. The 2nd point, the fundamental way you move with a pointer is re-orienting the pointer, either with mouse or touch.
mbgower: There is less motor requirements for tap than touch. You must orient the pointer to where you want to contact.
mbgower: If I have a trackball, every one has an assigned "drag" control.
mbgower: From user perspective, only difference in re-orienting pointer and dragging is difference between clicking a button and not clicking a button.
mbgower: It's in AT, not in O/S. I know not all the O/S's have given an assistive touch equivelent.
mbgower: Most O/S's provide some mechanism.
<Zakim> alastairc, you wanted to say about scrutiny
mbgower: I don't want to over-burden the author w/o research.
Alastair: We do get a lot of scrutiny from W3C members throughout the process, and they will ask for research.
Alastair: For some SC you can point to available research to support the motive.
Alastair: My concern with this is that we don't know that the author'd solutions are better than the platform or AT provided solutions.
Alastair: The solutions we mandate may not be better. If we aren't certain, I'm inclined to put it on hold.
Alastair: This could slot into 3.
Wilco: I'm surprised that this sc got this far w/o research. There's an argument for situational disabilities are not uncommon.
Wilco: I don't think this is difficult to meet, I don't know that it's a bad thing to say it needs to be supported without AT. Contrast is an example, style sheets have to have sufficient contrast.
Alastair: Pointer gestures, there were circumstances where even with AT you couldn't access some capability.
Alastair: It seemed logical to take the same approach to dragging. My point on the... I'm agreeing that yes with situational, mobility impairments, dragging is difficult. But are buttons more usable? I'm struggling.
Alastair: If we aren't certain, I'm inclined to not push this onto people.
Chuck: We have well intentioned thoughts. If we don't have research to back up a clear conclusion, I'm supportive of a more cautious approach.
Chuck: I'm hearing good intentions, but I'm also hearing presumptions and no research.
<Chuck> Poll: 1) Put on hold, 2) have reasonable answers for raised question on effectiveness...
<Chuck> Alastair: We have short time on getting those answers.
<alastairc> Poll: 1) Put the SC on hold for post WCAG 2.2 (2) Try to find answers (quickly)
<Chuck> 3) Leave it as is
<Chuck> Alastair: Situational is tricky, we are set up more for permanent disabilities.
<Chuck> mbgower: We had inside a charting application, there was a range control, a 2 point slider.
<Chuck> mbgower: I think the solution we found is not bad, and meets the criteria. We came up with a slider, 2 points at either end, if people can reduce data they can slide those.
<Chuck> mbgower: You can grab and define a range. We did by proximity. If someone clicks in slider, works very well from going from large range to small range.
<Chuck> mbgower: Get's tricky getting to small range, you can only get halfway between. Same thing going out, it's easy to go out, but fine tune the range is combersome.
<Chuck> mbgower: Meets the guideline, but probably frustrating to use. You can still use dragging, and still use keyboard.
<Chuck> mbgower: We didn't have any guidance on other ways to do it. People make stuff that meets the letter of the law, but may not be usable.
<Chuck> mbgower: I do wonder, most mobile interactions require dragging. When are we making the assumption on situational disabilities. Valid question.
<Chuck> mbgower: There may be sutiational where you can't use mobile.
<Chuck> AbiJ: Having watched this SC evolve, when it started, trying to encorporate it into existing practice, when you look into mobile there was a need, but now there is better keyboard access.
<Chuck> AbiJ: Now mobile O/S supports keyboard. a 3rd option is making sure understanding covers keyboard operable will cover most likely scenarios.
<Chuck> Alastair: Keyboard operables we have in 2.1.1
<Chuck> AbiJ: More that there were, where we encountered it is native app and web app on mobile which required a dragging action, were not possible to make keyboard accessible, and now they are more so.
<Chuck> Wilco: I think that argument goes for pointer gestures too. If we think keyboards are available and sufficient.
<Chuck> Wilco: The other thing I was wondering. Seems that there are no major objections. There are questions. Is that a reason for us to hold it?
<Chuck> Alastair: We didn't get a lot of issues raised externally. But that doesn't mean we won't in future.
<Chuck> Alastair: My concern with Abi's point, landscape is changing. Hard to tell if it's still an issue. where does keyboard accessibility overlap, what's the gap. It doesn't feel like we have a solid understanding how they inter-relate.
<Chuck> Alastair: Other sc not as much of an issue.
<Chuck> Alastair: With dragging it's a bit more complex. I'm struggling with... if we don't have a solid answer for when an author should provide a solution, it's difficult to justify.
<Chuck> Wilco: I don't find it hard. I hear "just use a keyboard for phone", that's a big change for a lot of people.
<Chuck> Alastair: If you have underlying o/s support, voice access...
<Chuck> Abi: Clarify - Carousel on mobile device, would there be support with screen reader to navigate? Yes, but would current SC consider gestures part of...
<Chuck> Abij: If you are considering keyboard access, you need single point of control. Therefore we have covered dragging requirement as well. I'm not saying you are making it keyboard accessible, I'm saying that to make it keyboard accessible you need single point of action.
<Detlev> the requirement here has always been separate from keyboard accessibility.
<Zakim> mbgower, you wanted to say I can live with any of the options, but I would love to try to find some research
<Chuck> Alastair: I'll need to think on that.
<Chuck> mbgower: If we are focusing on situational, there is some acknowledgement that with a permantent disability there are inexpensive ways to solve.
<Chuck> mbgower: I would like research, how many o/s's provide an equivalent for press and hold.
<Chuck> mbgower: Is that considered sufficient? If all major o/s's do that, would we still having this conversation?
<Chuck> mbgower: I don't know we have that research.
<alastairc> q/
<Chuck> mbgower: If somebody has the cycles to research this, that would be valuable. I'm fine with all 3 options, but I'd like to have a more informed decision.
<Chuck> Chuck: I don't know that I could defend and support his.
<Chuck> Alastair: One of the issues that I still need to respond to is from Google, asking how have we delt with the issues raised with WCAG 2.1, including having solid research to justify sc coming through. We will come under that scrutiny.
<Chuck> Alastair: People from google have been from accessibility point of view. We do get some negative feedback later.
<Chuck> Wilco: I'd like to ask how the availability of AT matters for this. It seems to me that yes AT exists, why does it matter how many there are for this sc?
<Chuck> mbgower: I've always understood that its part of the formula. How much does author do, o/s do, at do. Name Roll Value comes into play.
<Chuck> mbgower: O/S supports as well as common AT's available.
<Chuck> Juanita: Also, I'm aligned with what you are saying as well. I think the standards have used the O/S features as a model. If the O/S is trying to solve for this issue, it might make sense to follow their lead rather than find an alternative solution.
<Chuck> Juanita: We don't want to create conflict and force users to learn 2 systems.
<Chuck> Wilco: This line of thinking makes me nervous. Our other SC we are working on, this could be applied to. AT helps with target size. Focus appearance. We don't use it or rely on it.
<Chuck> Wilco: Why is this different? Should we reconsider others?
<Chuck> Alastair: No chair hat. It does tend to be part of the formula. One part is how much change to the intended design of an interface do authors have to make?
<Chuck> Alastair: Contrast does make a change to the design, but benefited many people.
<Chuck> Alastair: That was a reasonable ask of authors.
<Chuck> Alastair: Some of them are required for AT to work (name role value), and straddling middle ground asking authors to do things but allowing for personalization.
<Chuck> Alastair: If it impacts intended design, we ask for a higher bar. The thing I'm struggling with, would the solution that people come up with be better?
<Chuck> Alastair: If you are dropping onto 2 dimensions, and having to tap little buttons to travel, is that any easier than drag and drop? Is it easier when you've got assistive touch turned on?
<Chuck> Alastair: We can't answer the question, and that's my worry.
<Chuck> Wilco: Why are they not applicable with target size?
<Chuck> Alastair: They are.
<Chuck> Alastair: Hitting button compared to on mobile device, is that easier?
<Chuck> Detlev: To last point, that would need to be the only way of doing things. We had other examples where you could select an item and choose something from a select control.
<Chuck> Detlev: that may not need to be the only option. I have 2 points. I would really like to get input from orgs with individuals with multiple disabilities.
<Chuck> Detlev: I haven't heard back from people who may struggle with dragging. That would be interesting to see if people perceive as a real problem and barrier.
<Chuck> Detlev: Both in mobile and desktop. The other thing is it's a good suggestion to review current O/S and see if there are drag and hold options and how they work.
<Chuck> Detlev: I can take that up if we need to research and report on current state.
<Chuck> Alastair: We need to come to some decision about this. Our time is limited for 2.2.
<Chuck> mbgower: The SC exists. If detlev can dig and get some people to help, the effective decision on this will be that it goes through as is.
<Chuck> mbgower: Adding clarity would be helpful, there was clearly a mis-undersanding that needs to be cleaned up. If detlev is willing to look into it, then we don't have to take it out.
<Chuck> Alastair: Poll.
<alastairc> Poll: 1) Put dragging on hold, for post 2.2
<alastairc> (2) Update understanding doc & quickly find justifications
<Wilco> 2
<Rachael> 2
<ShawnT> 2
2
<Chuck> Alastair: If we can make the decision soon, we can still pull this if required.
<alastairc> Chuck: If Detlev does the research, and it isn't positive, is it an easy decision
<Chuck> Wilco: I have strong concern taking out. I'm not sure what research would show this is not relevant. It's about how many are out there are the unknown, and I don't see how this changes the SC.
<Chuck> Alastair: There would be an argument for making AAA if there was good support.
<Chuck> Alastair: The unknown is how effective the mobile equivalents are at the moment.
<Chuck> mbgower: If we found that all major o/s have a press and hold equivalent, would your position change?
<Chuck> wilco: I don't think so, doesn't change the need. WCAG isn't a thing that just changes as AT changes. This should be universal.
<Chuck> mbgower: There are o/s features like keypress equivalents. It's unusual to find a website that offers resize text. You could say authors are responsible for providing things like speed of mouse operation, but o/s's provide that.
<Chuck> mbgower: I thought that if every o/s offers a dragging equivalent with some personalization, there wouldn't be a need.
<Chuck> Wilco: My position differs. If support for focus appearance improves for browser, chrome has such, if that featuer is more available, does that make focus appearance obsolete?
<ShawnT> available does not mean users know about it
<Chuck> Alastair: It doesn't make it obsolete... bugs opened on some user agents for last 10 years. Even with better focus styles, there are still circumstances where it doesn't work.
<Chuck> Alastair: It's a universal focus indicator. There are things author can do to disrupt a good default browser focus indicator. If there were good options across systems for focus indicators, I wouldn't pursue that one.
<Chuck> Alastair: We wrote it in such a way that if browsers meet it, author doesn't need to do anything. For dragging, it's a case for how feasible it is for authors to implement something. We don't know if author generated approaches are better.
<Chuck> Alastair: I can't find an answer.
<Chuck> Juanita: There are far more browsers than O/S's. If the O/S were to fix focus indicators and do effective, then that would be more robust. I think generally O/S solutions that allow for using technology are better than browser solutions.
<alastairc> Chuck: Key question - does an author provided solution offer substantive improvements?
<Chuck> Wilco: That depends on solution. how can we prove that?
<Chuck> Alastair: We have examples of solutions that have been created. I don't know the answer if they are easier than actual drag and drop?
<Chuck> Wilco: So about the examples?
<Chuck> Alastair: Typical cases. If its a reordering, there are up and down arrows, drop downs that do with a single pointer. If these are the examples that we do, are those better? Do we know?
<Chuck> Alastair: We didn't tackle in 2.1 because we couldn't find any good examples that were pointer usable and keyboard operable. Resizing a box was very difficult to do.
<Chuck> Alastair: We need some evidence.
<Chuck> mbgower: Kahnban example, moving across boards. A suggested solution is a menu where you can choose where it's oriented. You've got a 20 item board...
<Chuck> mbgower: User will click on menu, drag the menu to get the item they want to find, press and hold. That solution users a gesture. Even that simple and reasonable solution, we don't have data for X users, is this an improvement.
<Chuck> mbgower: I take the point its just different solutions, but are the solutions we recommend a real improvement?
<Chuck> mbgower: If they don't really improve, why are we making the sc?
<Chuck> Alastair: Been on this one for an hour, need to come to conclusion.
<Chuck> option 2 had support.
<Chuck> Alastair: Is that a dead end for WCAG 2.2?
<alastairc> Poll: 1) Put dragging on hold, for post 2.2
<alastairc> (2) Update understanding doc & quickly find justifications
<ShawnT> 2
<Chuck> Rachael: re-poll, only had a few answers.
2
<Chuck> 2
<AbiJ> 2
<Jaunita_George> 2
<Detlev> 2
<Wilco> 2
<Rachael> 2
<Chuck> Alastair: I do think user agents are a factor.
<Chuck> Scribe change?
<Chuck> Alastair: If there's reasonable support, this question comes up again.
<laura_> 2
RESOLUTION: Carry on with SC
Detlev: Would it be helpful if we worked with some organizations that can assist?
Adobe Comment on 2.5.7 Dragging Movements #1886
alastairc: Please let us know if you know an organization that can help
<alastairc> https://
<alastairc> https://
alastairc: So Detlev has created a PR and I was going to propose was a little change
<Rachael> My memory is that there were some other changes that had to be made from a prior survey question and we needed those before we could move forward
<alastairc> "Where functionality can be executed via dragging movements and an equivalent option exists that does not rely on dragging and meets all other WCAG Success Criteria, this option counts as a <a>conforming alternate version</a> from the same page."
alastairc: the sentence at issue was "Where functionality can be executed via dragging movements and an equivalent option exists that does not rely on dragging and meets all other WCAG Success Criteria, this option counts as a <a>conforming alternate version</a> from the same page."
<alastairc> Where functionality can be executed via dragging movements and an equivalent option exists that allows for single-pointer pointer access without dragging, the success criterion is passed. It does not have to be the same component, so long as the functionality is equivalent.
alastairc: what I was going to suggest was that we say something like: " Where functionality can be executed via dragging movements and an equivalent option exists that allows for single-pointer pointer access without dragging, the success criterion is passed. It does not have to be the same component, so long as the functionality is equivalent."
<Wilco> +1
<mbgower> +1
<laura_> +1
alastairc: I think that tackles both commnets
+1
… any concerns?
… David was suggesting a change to the linear slider control
… The change is on line 84
<Detlev> +1 (I believe - I am not that fast...)
<alastairc> https://
<Detlev> +1 happy with this
<alastairc> David suggested, on line 84, "+/- buttons for minor adjustments to where the use clicked."
Detlev: You may need increment buttons, but in other cases that might not be the best solution
alastairc: That's a reasonable point
<alastairc> draft RESOLUTION: Accept PR 1961 as amended by the text above
<mbgower> +1
<Detlev> +1
<laura_> +1
<Wilco> +1
<ShawnT> +1
+1
… so John had a small change to update the example
… some of the comments discussed adding +/- buttons, removing the word "simply"...
… can an onscreen keyboard be used as an alternative to dragging?
<Rachael> +1
RESOLUTION: Accept PR 1961 as amended by the text above
Is keyboard functionality acceptable if an on-screen keyboard can be used. #1978
<alastairc> https://
<alastairc> https://
<alastairc> "A radial control widget (color wheel) where the value can be set by dragging the marker for the currently selected color to another position, also allows picking another color value simply by tapping or clicking on another place in the color wheel."
<Detlev> someone wanted to get rid of "simply"
<Zakim> mbgower, you wanted to say I'm concerned about taking out the input
mbgower: My sense here is that John was asking that allowing someone to enter a color value was equivalent to dragging?
… I don't know why we wouldn't say it's an alternative
alastairc: In the thread, I think where we got to was that the keyboard would fulfill the SC, but we don't want to recommend that.
<mbgower> I'd add both
<ShawnT> +1 Detlev
Detlev: Many color wheels do provide color input and that helps, but the experience is different from those using the dragging motion
alastairc: We're taking out the reference to keyboard to address Detlev's concern. Detlev has responded to David's comment. We do not want to be as proscriptive.
<alastairc> draft RESOLUTION: Accept PR 2009
+1
<mbgower> +1
<Detlev> +1
<Rachael> +1
<ShawnT> +!
<ShawnT> +1
<Wilco> +1
RESOLUTION: Accept PR 2009
Exception for web content used by the author but generated by the user agent? #1977
alastairc: *reads through survey responses*
<alastairc> Poll: 1) User-agent controls are in scope of the SC
<alastairc> 2) user-agent controls are not in scope of the SC
<Wilco> 1
<Detlev> 2 - I would keept to to things that authors can influence
mbgower: Wasn't there some language about this at some point in the SC?
alastairc: I can't think of any native user controls that would require a gesture
mbgower: We should at least have some language that it's not in scope.
<Chuck> NOTE: I have other calls to prepare for and participate in for the next 2 hours. I will depart and return later.
mbgower: A video player is a user agent
Detlev: Maybe there's a good distinction to be made between a native video element and something like the YouTube player.
alastairc: reconvening in 30 minutes
alastairc: We're still looking at dragging and browser-based video controls
<Regina> I'm back
mbgower: We haven't found any standard HTML component that fails. If we do not provide an exclusion for native browser behavior, people will have to test quite a bit and might create a custom solution. It's better to raise the issue with browsers themselves rather than developers creating their own video component
alastairc: This is exactly the same for keyboard accessibility where there isn't an exception and there are cases where native browser implementations are not accessible -- an example being Opera's date picker
mbgower: What happens if there's an issue?
ShawnT: I remember having a discussion with Wilco. There are so many things a developer can override, so they should be responsible, but I'm not sure I agree.
alastairc: Do we try to define whether authors are expected to override basic behaviors or remain silent
Wilco: I think we can leave it as is? It's the gray area I was not keen on. If we want an exception for user agents then we should make that explicit.
<Detlev> But you wouldn't be 'off the hook' with something like the Youtube Player, right?
<alastairc> All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential, or defined by the user agent and not modified by the author.
<Wilco> +1
+1
<Detlev> +1
mbgower: Maybe we should add boilerplate language that adds a provision for non-interference with browser behavior
<Zakim> mbgower, you wanted to say that this idea could potentially fit in the Conformance section after Non-interference
<alastairc> "All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author."
mbgower: I think it would be good to add an example to the understanding document
<ShawnT> +1
<mbgower> +1
<Detlev> +1 yes
+1
<Wilco> +1
<Regina> +1
<MelanieP> +1
<laura_> +1
<Rachael> +1
RESOLUTION: Agreed response to #1977
+1
Does the Definition of "Dragging Movements" Intentionally Limit the Scope to Moving Objects/Items? #1560
alastairc: I remember that this was complicated and there were lots of examples. Is there a summary Detlev?
<Rachael> I added the discussion of "determined by user agent...." to line 11 of the draft schedule for the accessibility supported subgroup to discuss.
Detlev: Not at the momemnt
alastairc: My question is can we take this and slightly modify it and merge it later. It's informative content. Is it adding an improvement?
<Detlev> Should I take over scribing?
MBG: Things lie drwing rects do not seem quire in scope - or we need to modify out definition of dragging movement...
AC: (going through Suzanne Taylor's examples)
MBG: (thinking aloud) - "engages on an element" may be the problem
AC: free-form pointer movement was not intendedto be covered
AC: Had difficulty understanding the examples
MBG: (want's Wilco's brain power now :)
MBG: Currently definition refers to an object
Wilco: Distinction is more fuzzy
AC: Not sure we want to cover 'leavign a trail'
Rachael: Have not thought about it in terms of drawing - inclined to leave ti out
AC: In terms of the current definition we could say, we are covering a subset of dragging scenarios
… we don't want to change it
AC: Any improvements, anyone?
AC: Additional coverage of drawing rect dio niot seem to add much
Wilco: SHould we add a note to definition saying that line drawing is not in scope
DF: Where is the problem in including rect draing and the like?
MBG: The problem is only one person agrees with the update - may not help understanding
DF: Tackle in pass though understanding doc?
MBG: We don't know enough now to cover it well
Wilco: The lines a fuzzy as to what is or isn't dragging
AC: It is an arbitrary line - dragging wires across to connect matching things - in terms of our definition as you see it, it would be in scope, if its rendere dafterwards, it wouldn't be in scope
<Zakim> mbgower, you wanted to say we want to ensure that repositioning on a page is not in scope
MBG: We do not want to make th edefinition so wide that people will think even dragging up and down pages is in scope
AC: (shows update of Rachael in survey comment) - can we use this as placeholder pending update of the understanding doc?
<alastairc> draft RESOLUTION: Accept the amened PR, knowing that the document will be further reviewed soon.
<mbgower> I can live with that
<Rachael> +1 assuming review
+1
<mbgower> +1 with reservation
MBG: THis SC needs illustrations
<Wilco> +1
RESOLUTION: Accept the amened PR, knowing that the document will be further reviewed soon.
Exceptions seems like free form paths rather than dragging #1979
AC: (reading issue and PR changes)
<alastairc> "when playing a game where the aim is to quickly drag an element over a moving, jumping, or suddenly emerging drop target."
AC: separate it from free-form drawing - any concerns with the PR
MBG: We had exceptions in game context - better have an example where there is no other way to achieve the result
AC: Does addtion improve understanding doc?
MBG: Why can't you just click on it?
AC: Nota click task - like dragging stuff to particular emerging positions
AC: alternative to take out the exception but that would make me nervous
Rachael: Remove example?
AC: Then people will ask for examples...
<mbgower> I don't think it helps, personally
AC: Is the example confusing?
<alastairc> Poll: (1) Remove the example,
<alastairc> (2) Accept the PR update
DF: Clicking is no the same thing, you have to pick one element first
MBG: Can be done with sequences of click-click
Rachael: Leave example in, remove example for now
sotrty leave exception in
AC: We should leave the exception in but remove example
<mbgower> 1
<alastairc> 1
<ShawnT> 1
Don't care either way...
<Wilco> prefer 3, won't lose sleep over the other 2
<Rachael> 1
MBG: Throw action instead - would be a path-based gesture
<alastairc> draft RESOLUTION: Remove the example from the understanding document.
MGB: Flicking cards - would not really point-to-point
RESOLUTION: Remove the example from the understanding document.
phew
<Rachael> ::celebration::
Accessible authentication https://www.w3.org/2002/09/wbs/35422/wcag22-accesssible-auth-updates/results
Further guidance on 2-factor independent methods #1965
AC: (covering Issue, PR, reading changes)
… added QR code example
AC: Touching on Rachael's response
Rachael: Issue of ANDS and ORS, lack of consistencey
AC: will tidy up editorially
MBG: Address question on user name?
AVC: You are ahead of us
AC: Will make those changes to amend PR - everyone happy?
<Rachael> draft RESOLUTION: accept PR as amended by survey comments
+1
<Wilco> +1
<laura_> +1
<Rachael> +1
<Jaunita_George> +1
<mbgower> +1
<alastairc> +1
<ShawnT> +1
RESOLUTION: accept PR as amended by survey comments
Google feedback #1890
<Zakim> mbgower, you wanted to say don't address 'Most of our new comments/proposals are requests to: clarify whether remembering your own username is a cognitive function test'
AC: Google feedback was whole document, was separated in different sections
MBG: Remembering user name is not considered a cognitive function test
AC: It is in the difinition
AC (reading the Definition of 'Cognitive Function Test') - so user names ARE cognitive function tests (as you may not be free to pick on that you can easily remember)
MBG: As long as you rememeber your email, you can usually change other aspects
<alastairc> Response: https://
AC: Other concerns with response?
<kirkwood> does rembering which email you used count as a cog function test?
Shawn: six email adresses - and remembering each is a coginitive function test
from a user perspective it can still be difficult
MBG: It was put this way since without a mechanism for contacting someone (phone, email) it is almost impossible to implement an authentication mechanism
Shawn: makes sense
<ShawnT> +1 Rachael
<kirkwood> +1
<alastairc> " are not considered cognitive function tests as they are personal to the user and consistent across websites;"
Rachael: We've had that phrase "are nit considered cognitive function tests" - needs to be changed to something like 'in the context of this SC'
MBG: (rephrasing)
<Rachael> "are not considered cognitive function test for purpose of this SC"
AC: Definitions are independent of SCs so we need to put thi smore generally
<mbgower> for the purpose of conformance, as they are personal to the user and consistent across websites
MBG: Start with 'For the purpose of conformance..."
<Rachael> needed for indentification
<kirkwood> need for secure authentication
<mbgower> for the purpose of conformance, as they are personal to a user, consistent across many websites, and needed for communication
AC: (wordsmithing)
<Chuck> back in the call
<alastairc> for the purpose of conformance, as they are personal to a user and needed for communication
MBG: how about "not defined"?
<Rachael> "not included in" ?
AC: Authentication os the whole process - this is a precursor to ath (where do I sent the request to)?
<mbgower> The common identifiers name, e-mail, and phone number are not included as they are personal to the user and required for communication
AC: replacing a part of the Cognitive Function Test definition
<Chuck> draft RESOLUTION: Accept the response to 1890 and update the defintion as amended
<Rachael> +1
+1
<kirkwood> +1
<alastairc> +1
<ShawnT> +1
<laura_> +1
<Jaunita_George> +1
Wilco: Was "such as" in it?
… it's a little biased
… in favor of people using phone numbers and email addresses
MBG: Wilco has a point - are we being too prescriptive?
AC: We got down to this narrow list of things that you need to start authenticating
MGB: Once email is no longer the preferred method, we can change it
<Chuck> +1 to Rachael
RESOLUTION: Accept the response to 1890 and update the definition as amended
<kirkwood> +1
<alastairc> Break now, back in 1.5 hours
<alastairc> https://
Page break navigation https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/results
<Regina> I'm back
<Rachael> https://
Rachael: Picking up on page break navigation
<Rachael> https://
Alastair: Initially thought this needed a new technique, but getting more into it an update to the technique was fine.
<Rachael> draft RESOLUTION: accept PR 1226 as is
<laura> +1
<Chuck> +1
<alastairc> +1
<Detlev> +1
<ShawnT> +1
<mbgower> +1
<Regina> +1
+1
RESOLUTION: accept PR 1226 as is
Overly prescriptive? #2026
<Rachael> https://
<Chuck> I will scribe for Wilco if he wants to talk to his response
Alastair: Another comment we've had a few times.
… What people didn't seem to understand is that it's quite a narrow scope. It only applies if it's EPUB-like, rendered by the browser, with HTML, and has programmatic markers.
… If you meet that, you have to provide a mechanism.
… It's not a burdensome requirement for a standard website.
Rachael: So the topic is whether the SC is relevant at all
Chuck: In this case, the platforms that do this, therefor it passes and so we don't need it.
… I find it interesting it's a fairly similar point here.
Alastair: This came from EPUB, it was part of a pair of potential SCs. The first one was that content should have page break locators.
… The second is if you have locators, you need a way to get to them.
… A lot of educational material has the page break locators, but browsers don't provide a mechanism.
… There is a note in the understanding doc that says; PDF has a mechanism, EPUB have a mechanism, web browsers do not.
… It's the only one from them we've managed to get anywhere.
<Zakim> mbgower, you wanted to say "accessibility supported" is a conformance requirement
Mike: I'm in line with Wilco on this. I don't think we have to specify the mechanism is accessibility supported.
… I can live with it, but am bothered we didn't do more with it.
… The language of pages and pages in the set sounds like "set of web pages"
Alastair: A kindle book does not seem like a set of web pages.
Mike: Pagination in a table for instance fits into a model.
… A horizontal list of pages works pretty well with that. Maybe that definition is the problem. It implies to me a set of pages.
Shawn: In Fedgov we see a lot of Word documents that end on the web. Page break locator sounds like referring to something further in the document would need to be linked.
<Rachael> Strawpoll: 1) Defer SC from 2.2 2) Continue as is 3) continue with revisions
Alastair: Recommend if there was strong objections we'd have a meeting with EPUB folks.
… They made a good case for it.
<Chuck> 2
<Detlev> 2
<alastairc> 2
Alastair: We've compromised a lot, I'd be hesitant to throw it out
1
<Rachael> 2
<laura> 2
<ShawnT> 3
Mike: Maybe under the definition we could tweak it. If we can get an "or set of web pages" in there.
Alastair: It's not necessarily a web page. The pages are from another format.
Mike: It has to be does it not? For WCAG we have to talk about a locator that points to other web pages.
… It's a mechanism.
Rachael: Wilco in the next question brought up printable pages, to distinguish it from web pages
… If it's not a web page, what is it
Alastair: The page it's referring to could be a web page, but it's more likely to be a location on the current web page.
… For the purpose of going to a page, that is the term.
Mike: I think I might have something
<mbgower> programmatically determinable destination markers that are arranged in a meaningful sequence to determine a location in a page or set of pages
Wilco: That sounds like IDs to me
<ShawnT> to me it sounds like a Table of Content?
Alastair: It's more specific than an ID that goes to a location
… It's pages that align with a print edition.
Mike: Our definition of WCAG is around a page. We mean this as a page representing a physical thing.
… Our assessments are all about a page.
Alastair: Yes, pretty much.
<Rachael> what about page-reference?
Shawn: Locator threw me off
… I have a publishing background, I never heard that term.
<Chuck> I'll scribe for Wilco
Alastair: This is our own known technique for this. An HTML element that has a particular role and label.
… There would be some kind of listing to go through that
https://
<Chuck> Wilco: My understanding on what we are talking about and what we are only talking about is (link provided)
<Chuck> Wilco: This is what we want to have a list of, plus accessible name. Nothing else. The whole thing for us formulating this that's technology agnostic...
<Chuck> Wilco: The role and nothing else is what is making this confusing.
<Chuck> Alastair: We try to word it not specific.
Rachael: We seem to have slight consensus on continuing with this SC
Mike: I can live with it as it is. We understand the constraints
Alastair: There is a very specific educational setting where it might make a big impact
<Chuck> No objections
Rachael: Any concerns to link to the word mechanism?
Alastair: We can do that
<Rachael> Draft RESOLUTION: Accept response and add a link to the word “mechanism” in the SC
<Chuck> +1
<ShawnT> +1
-.9
<laura> +1
<Regina> +1
<alastairc> +1
<Detlev> 0 not familiar enough with the context
Rachael: Suggest we move forward
Alastair: A form with EPUB folks in it would be a way to move forward
Michael: Lets go through it, we should have this conversation for WCAG 3.
Chuck: Does move forward mean accept the resolution. Looks like we have enough consensus.
<mbgower> The closest I could get to a variation was: programmatically determinable destination markers that are arranged in a meaningful sequence to represent the page breaks in the printed version of a document
Alastair: Given where we are with WCAG 2.2 publishing, we've had those conversations. Some people aren't persuaded. If they can live with it we can move on.
Chuck: I think we have the conversation, but let WCAG 2.2 move forward.
<alastairc> mbgower - it may not be printed
Rachael: The key question, will anyone object formally.
Wilco: I will not object to it
Rachael: Lets move forward with it
<Rachael> Draft RESOLUTION: Accept response and add a link to the word “mechanism” in the SC and plan epub requirements discussion for 3.0
<Chuck> no objections
<Detlev> fine
<Jaunita_George> no objections
RESOLUTION: Accept response and add a link to the word “mechanism” in the SC and plan epub requirements discussion for 3.0
Are slides included? #1867
<Rachael> https://
Rachael: 3 people agreed, 1 person someone else
… Do we need to clarify "page" in some way?
Mike: I think we want to come up with something other than just the word "page".
… If we can clarify that it could cut down a lot of confusion.
Alastair: I agree, but don't see a nice solution. That's where we've had a lot of trouble.
… When we talk about EPUB, that is somewhere between a page and a set of web pages.
… There was a massive thread on the list. That's a known problem.
… This is slightly different, where you have a non-EPUB document that has a similar structure.
… We have this other concept of, I'm no a web page, but I can go to a page.
Rachael: Suggest we accept this particular response, and go back to EPUB if we can better clarify.
<Chuck> +1
<mbgower> The closest I could get to a variation was: programmatically determinable destination markers that are arranged in a meaningful sequence to represent a locator serving the same purpose as page breaks in a printed document
Rachael: It doesn't seem like we have the right people here to do that definition now.
<mbgower> programmatically determinable destination markers that are arranged in a meaningful sequence to represent a locator serving the same purpose as page breaks in a printed document
Chuck: This kind of blends into what WCAG 3 is trying to do. As far as WCAG 2. We have to be really cautious. We have a definition of page. If we're going to clean it up, we have to clean it up for everything.
Mike: My suggestion infers what we're trying, getting away from the word page.
<Rachael> draft RESOLUTION: Accept response, revisit the word “page” as used in this SC with Epub contribution.
<mbgower> YES!
Alastair: Would it be easier to add a note saying that "page" is not web page, referring to digital / printed additions of pages.
Mike: Are notes normative?
Wilco: no
<Rachael> draft RESOLUTION: Accept response, add a note to clarify what page means here.
Mike: I'm okay with it as a note.
<Chuck> Wilco: I like the direction where Mike's going, would like to explore it more.
<Chuck> Wilco: Notes are easily overlooked.
<Rachael> draft RESOLUTION: Accept response, revisit the word “page” as used in this SC with Epub contribution or add a note to clarify what page means here.
<ShawnT> +1
<mbgower> Suggested wording to explore: programmatically determinable destination markers that are arranged in a meaningful sequence to represent a locator serving the same purpose as page breaks in a printed document
<Jaunita_George> +1
<Chuck> +1
Rachael: We'll explore the definition more. If we can't we'll clarify with a note
+1
… Mike, if you're willing, and Wilco, maybe a few more can come up with a resolution.
<mbgower> +1
<alastairc> +1
<Regina> +1
<Detlev> +1
Mike: I'll open a new issue for this.
Update page-break-navigation.html #2094
RESOLUTION: Accept response, revisit the word “page” as used in this SC with Epub contribution or add a note to clarify what page means here.
<Rachael> https://
Rachael: 4 agreed, 1 agreed with adjustments. All of my comments were editorial.
Alastair: Should this say "alter the layout of content" or pagination.
<Rachael> draft RESOLUTION: Accept PR with amendments as discussed
Rachael: We can accept the PR, and then do refinements
+1
<ShawnT> +1
<Rachael> +1
<Chuck> +1
<Regina> +1
<mbgower> +1
RESOLUTION: Accept PR with amendments as discussed
Visible controls https://www.w3.org/2002/09/wbs/35422/wcag22-visible-controls/results
Visible controls re-write
<Rachael> https://
Alastair: Had discussion on this before. This PR has been updated since then.
Rachael: 2 agreed, 2 with some adjustments
… Question on the table is to add a note on where/how to reveal the hidden control.
Rachael: Is there a draft note we can add here?
Alastair: From our original wording, I don't think there was a requirement that the indicator should include how/where to find the control.
… The indicators we've looked at sometimes didn't give on indication because they were the location.
… I don't want people to think they need to provide an icon of sorts.
Wilco: Can go with it either way, as long as it's clear which way this goes.
Mike: I think where this is going is clear. I like the rewording. The scenario seems clear to me.
Wilco: Not a problem with the new wording, I read too much into previous. I realized that I was reading more into it than was there.
Wilco: The word "identified" was to me that you need to make clear.
Rachael: Do we need a new issue? And discuss that? Is that the right next step?
Rachael: it seems out of scope for this issue.
Wilco: Is it part of the SC on how or where to reveal the hidden control.
<Rachael> strawpoll: Should an indicator per this SC include information on how or where to reveal the hidden control?
<mbgower> No
no
<ShawnT> no
<Wilco> Yes?
<alastairc> Not as a must, but could be recommended (in understanding)
<Rachael> yes, in that most indicators should be located at the point where an interaction is needed
<Jaunita_George> +1 to alastair's comment
<Detlev> no? Because it may nit work that way in all contexts
<laura> +1 to ac
Wilco: Usually the indicator is at the place of the control.
Rachael: No chair hat, this is to help find a control. If the indicator is not at the point where the hidden control is, there needs to be some call for it.
Rachael: Otherwise you could have an indicator that's not clear.
mbgower: The context is that this is a design SC. It's not directed at developers, it's directed at designers. You've got a page, and unless the user explores the page, they don't realize there is an interactive component.
mbgower: Suddenly they get a bunch of menus for that item. The idea is that if there is nothing visually there to indicate its interactive, then you have an issue.
mbgower: Instructions solve this, but not the only solution. think of something that has a drop down icon. It's providing an indication that not only can it be acted upon, it also indicates what will occur.
mbgower: The scenario I see is that you are in some kind of editor and a word doc for instance, the word itself is a mechanism to provide actions. If you don't understand the interaction, you may not realize that you can do something with it.
mbgower: There should be something visible.
Alastair: I think that back on the examples, there were scenarios where you would want it separate. A table with every cell editable, you don't want to introduce icons everywhere, but you could provide a single instruction on how to edit the table.
<mbgower> or a pencil icon (for example)
Alastair: It's a common sense logical approach to state where it is. In the instance where the thing itself is the indicator, I don't think you need to have it as a requirement.
Rachael: <proposing wording>
<Rachael> Note: When text instructions are used to indicate a component, that text should include where and how to interact with the component.
<Detlev> Too prescriptive, agree
mbgower: Seems perscriptive. Alastair's example is a good case. If the user hovers over the table and instructions are provided, that would fail, but written instructions or a pencil at the top is an indication of the actions.
mbgower: that's what I think we are trying to solve.
wilco: would text instructions fail?
mbgower: no, but the instructions need to explain where and how.
wilco: What if it says there are hidden edit buttons in the table?
rachael: if there's an edit component, and you click and things become editable, you have an indication at every point. I don't think this fits the problem.
Top of hour scribe change?
mbgower: I may not be following well.
Wilco: It seems we haven't settle on the 'where' 'how' information
Chuck: We did have a straw poll. It looked 50/50
<Rachael> strawpoll: Should an indicator per this SC include information on how or where to reveal the hidden control?
<Chuck> No?
<Detlev> not always
<Rachael> yes in some form
<Wilco> yes, won't lose sleep over no
<alastairc> No, but strongly hint (with examples) that it is useful in some scenarios
no, as no it doesn't have to. this is not a instruction requirement
<ShawnT> Oui
Alastair: This wasn't required before, and I think it would become quite prescriptive
Alastair: Hints and tips and recommendations can be in the undersatnding document.
Wilco: You didn't think this was required before but some did, including me.
Alastair: Does identify mean something different in another language?
<Zakim> Chuck, you wanted to say I agree that describing the interaction will be "heavy"
Chuck: I have a concern. If we were to try to describe or prescribe an interaction, it's going to be a heavy lift.
Chuck: We're going to have to be cautious
<alastairc> If people did assume that (and didn't complain about it), and we remove that requirement, that should be ok...?
<alastairc> It went from "important controls" to "hidden controls" to "visible controls".
Rachael: This concept of having instructions was not originally part of this.
Wilco: Should we ask who can live with not including this?
<Rachael> draft RESOLUTION: accepting this PR And including suggestions on how and where as part of understanding but not requiring it
<Chuck> +1
+1
<alastairc> +1
<Detlev> +1
<laura> +1
<Jaunita_George> +1
<Wilco> 0, as long as we make it clear this is not required
<Rachael> -.2
RESOLUTION: accepting this PR And including suggestions on how and where as part of understanding but not requiring it
<Chuck> Are we closing more than we are opening?
The first exception is difficult to understand #1760
<Rachael> https://
<Chuck> No objections
<Rachael> draft RESOLUTION: Accept response
<Wilco> +1
<Chuck> +1
<laura> +1
<Jaunita_George> +1
+1
<Rachael> +1
<Detlev> +1
RESOLUTION: Accept response
<Chuck> no vote required
Subjective judgement is needed #1877
Altering bullet to make components persistent #2125
<Rachael> This topic is not valid after prior discussion. Can close wihtout vote
Subjective judgement is needed #1877
<Rachael> https://
Rachael: We only had 2 responses. Does anyone else want to speak to this?
<Rachael> draft RESOLUTION: accept response
<Chuck> +1
+1
<Rachael> +1
<laura> +1
<Jaunita_George> +1
<Detlev> +1
RESOLUTION: accept response
Understanding doc updates
<Rachael> https://
<Rachael> draft RESOLUTION: Accept PR
+1
<Rachael> +1
<Chuck> +1
<alastairc> +1
<laura> +1
<Detlev> +1
<Jaunita_George> +1
<Wilco> +1
RESOLUTION: Accept PR
Controls that require scrolling to reach #1875
<Rachael> https://
<Rachael> draft RESOLUTION: Accept PR
<Detlev> +1
<laura> +1
+1
<Wilco> +1
<Rachael> +1
<Chuck> +1
<Jaunita_George> +1
<Regina> +1
RESOLUTION: Accept PR
Update visible-controls.html #2095
<Rachael> https://
<Rachael> Duplicate doesn't need vote, can close
Redundant entry https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry/results
Clarify "available for the user to select." #1973
<Rachael> https://
<Jaunita_George> Rachael: Any concerns with PR?
<Rachael> draft RESOLUTION: Accept PR as ammended
<Chuck> I can go either way.
<Jaunita_George> +1
<Wilco> +1
<Chuck> +1
<Jaunita_George> Chuck: Neither of those is jumping out as easier to read
<Rachael> +1
<Detlev> +1
RESOLUTION: Accept PR as ammended
Consistent help https://www.w3.org/2002/09/wbs/35422/22_consistent_help/
Remove explanation of help mechanisms #1881
<Rachael> https://
<Jaunita_George> Rachael: Patrick made a suggested adjustment. Any concerns?
<Jaunita_George> alastairc: We didn't remove any content, just separated to make it easier to understand
<Jaunita_George> Rachael: Any concerns with Patrick's edits or the PR?
<Rachael> draft RESOLUTION: Accept PR as amended in survey
<Jaunita_George> +1
<Detlev> +1
<alastairc> +1
<Wilco> +1
<laura> +1
<Chuck> +1
<ShawnT> +1
<Rachael> +1
RESOLUTION: Accept PR as amended in survey
Clarify situations where some pages in set provide no help #1972
<Rachael> https://
<Rachael> draft RESOLUTION: Accept PR
<Jaunita_George> +1
<ShawnT> +1
<Chuck> +1
<Detlev> +1
<laura> +1
<Regina> +1
<alastairc> +1
<michael> +1
RESOLUTION: Accept PR
Questions to resolve for consistent testing #2068
<Rachael> https://
<Jaunita_George> Rachael: Alastair proposed response in #2115 and there were some agreements and some suggestions
<Jaunita_George> alastairc: It's about relative order. Items that appear on multiple pages should have the same relative order.
<Rachael> draft RESOLUTION: Accept PR but keep question of SC text open until we look at other PRs
<Wilco> 0
<Jaunita_George> +1
<Detlev> +1
<alastairc> +1
<Chuck> +1
<laura> +1
<ShawnT> +1
<michael> +1
RESOLUTION: Accept PR but keep question of SC text open until we look at other PRs
Wording is perhaps confusing #2098
<Rachael> https://
<Jaunita_George> alastairc: The key features are the "unless a change is initiated by the user" and the other feature would be to make it generally easier to understand. Then there was a note added which explains relative order.
<Jaunita_George> Wilco: I liked the one we looked at first more.
<Jaunita_George> Rachael: Let's look at both and the comments
<Jaunita_George> ...How would we like to make this adjustment. Patrick and Wilco agree with 2145
<Jaunita_George> Rachael: The only question I have about 2145 is that if I open it on a website and on mobile what would that do to the SC?
<Jaunita_George> alastairc: Consistent across pages on that device and orientation
<Jaunita_George> Rachael: Consistent on that variation then
<Jaunita_George> Wilco: Wording might not resolve the concern
<Jaunita_George> alastairc: Issue it's not totally clear if help is gone, does it fail SC if other pages have that help
<alastairc> If this page contains any of the following help mechanisms, and those mechanisms are repeated on multiple <a>web pages</a> within a <a>set of web pages</a>, they occur in the same relative order to other page content, unless a change is initiated by the user:
<alastairc> If a <a>web page</a> contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a <a>set of web pages</a>, they occur in the same relative order to other page content, unless a change is initiated by the user:
<Jaunita_George> Rachael: 2.4.3 says "if a page can.."
<Rachael> draft RESOLUTION: accept PR 2145 as amended to close Issue 2098 and 1693
<Jaunita_George> Wilco: The "if this" wording is a little odd for a SC
<Detlev> Still not quite getting how this goes beyond Consistent Navigation...
<Detlev> But don't want to be in the way :)
<Jaunita_George> alastairc: This is relative to other page content
<Rachael> draft RESOLUTION: accept PR 2145 as amended to close Issue 2098 and 1693
<Jaunita_George> +1
<laura> +1
<Rachael> +1
<Detlev> +1
<ShawnT> +1
<Wilco> +1, with the caveat that I'm getting tired
<kirkwood> +1
<Chuck> +1
RESOLUTION: accept PR 2145 as amended to close Issue 2098 and 1693
Consistent Help understanding and technique edits #2092
<Rachael> https://
<Rachael> draft RESOLUTION: accept PR with fixed link to correct understanding document
<Wilco> +1
<Jaunita_George> +1
<Rachael> +1
<michael> +1
<alastairc> +1
<Detlev> +1
<ShawnT> +1
<Jaunita_George> Zakim: Make Minutes