Accessibility Guidelines Working Group Teleconference -- 15 May 2018

<AWK> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 15 May 2018

<AWK_> zaki, clear agenda

<marcjohlic> scribe: marcjohlic

Understanding changes to review and approve: https://www.w3.org/2002/09/wbs/35422/understanding_changes3/results

Changes to Understanding Concurrent Input Mechanisms

PR: https://github.com/w3c/wcag21/pull/915/files?utf8=%E2%9C%93&diff=split

Proposed version: https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html

AC: Mostly editorial suggestions.. Andrew may have something more substantive

AWK: Felt that the language is perhaps a bit difficult - particularly "at any point" piece

AC: From a SC point of view it doesn't say that either way does it

AWK: Don't think it does

KW: Intent of the SC is to allow users to switch input mechanisms at any point so that we're not restricting it. We're not restricting the ability of users to use any input
... how we test it is different, but the intent is that a user should be able to switch at any point
... don't see it conflicting with SC - it's not that we're testing at everything single point and time

AC: Do we have a list of things to look for?

KW: We do - because you're looking at input agnostic handlers. We have 2 techniques and 2 failures - and those are the things you'd be looking for
... we went around and around to ensure it was testable.
... Fine with removing "at any point", but that is the intent behind this one

<jon_avila> I use the situation that Bruce describes all of the time

Brooks: Would like to leave it in there. Scenario wear a mouse user selects a link on the left and focus moves to main content - maintaining that focus regardless of your method of input should be the requirement

AWK: Agree completely with Kathy - one thing if we're not changing at any point - so maybe change "must" to "should" in the statements

KW: Fine with that change

AWK is making the edits

Bruce: Fine with AWK's edits

AC: Mike Gower was hoping to change "A user must be able to switch input mechanisms at any point should the user determine that..." to "Users must be able to switch input mechanisms at any point should they determine that..."

MG: I think the changes that AWK made fix that
... I think the final example should read "A speech input user navigates content using voice commands which translate to simulate mouse (and keyboard) commands. When talking with a colleague, however, the user turns speech recognition off and uses the mouse instead." My rationale is that the original sentence implies the mouse can achieve the equivalent to keyboard input, but this may not be true (without the use of an onscreen keyboard, which

arguably does not fit into this SC).

AC: Looks like a fairly small update to the last example - would anyone object to that?

No objections

MG: I suspect the first bullet of the failure techniques should be two bullets worded something like "Using only touchscreen event handlers based on the presence of a touchscreen." or else genericized to be something like "Restricting event handlers based on the presence of a detected input mechanism"

AC: Fairly straightforward update

AWK: So that's replacing the whole bullet?

AC: Do we have technologies in Failures?

AWK: Yes
... OK with change - just trying to understand definitely what gets swapped out

MG: Was just trying to find something a bit more generic

<alastairc> "The intent of this Success Criteria is ensure that web content not limit the variety of input mechanisms that might be used for interacting with that web content."

AC: Bruce would suggest tweaking lead to: "The intent of this Success Criterion is to ensure that web content not prevent users from choosing their method of inputting information."

<alastairc> "The intent of this Success Criterion is to ensure that web content not prevent users from choosing their method of inputting information."

<laura> +1

<Detlev> +1

<Brooks> +1

<JakeAbma> +1

<Makoto_> +1

AWK: Can we make that positive instead?

BB: This is one of those "do no harm" SCs - should the intent go to the content or to the bigger reason for the SC

<Zakim> bruce_bailey, you wanted to change doable to possible

AWK: And bigger reason is to allow folks to use whichever input device?

BB: Correct. I always thought the Intent statement was about the content. The content doesn't permit the user to do something - it just doesnt' get in the way of the user.

<Detlev> thanks..

BB: Agree I don't like the negative - but it's a "do no harm" SC

AWK: I can go either way

<AWK_> "The intent of this Success Criterion is to ensure that web content allows users to choose their method of inputting information."

MG: The SC is worded in a specific way, so if we can explain it in a different way that could be useful

<jon_avila> at any time

<Detlev> can#t hear you jon

sorry - didn't catch what Jon said

AC: Believe Jon was saying add "at any time" because it's not just at page load

AWK: We're still trying to sort out positive or negative

<Detlev> I think Bruce has a point that negative is more appropriate here

<AWK_> Jon's suggestion? "The intent of this Success Criterion is to ensure that web content allows users to choose their method of inputting information at any time."

AC: How are other Intent statements? Do they always mirror SC? Given that SC will be at the top of these Understanding docs it doesn't bother me to state in another way.

<jon_avila> I don't have a preference if it's positive or negative because it's the intent section.

<Zakim> bruce_bailey, you wanted to ask if we can get rid of ensure in opening intent statement?

DF: Trying to reformat it in a way that makes it more elegant by makes it still say the same thing.

BB: OK phrasing positively - but would like to avoid the word "ensure"

<AWK_> The intent of this Success Criterion is to allow users to choose their method of inputting information at any time.

BB: Think AWK got it with this edit

<bruce_bailey> The intent of this Success Criterion is that web content allow users to choose their method of inputting information at any time.

AC: Any other comments on this one?

<AWK_> "The intent of this Success Criterion is that web content allows users to choose their method of inputting information at any time."

<Brooks> +1

<Chuck> +1

KW: Think it sounds weird. The Understanding is supposed to make it easier to understand and I think we're adding complexity to this one. I object

LC: Agree - this one should about the people

<AWK_> possible variation on Laura's original: "The intent of this Success Criterion is to ensure that people can use different input devices when interacting with web content."

LC: In newer ones we're referring to people

<Detlev> easier

BB: If we're making these more people centric that's fine, but should do it soup to nuts

<jon_avila> The intent of this Success Criterion is to ensure that people can use and switch between different input devices when interacting with web content."

AC: We were going to go through all of the intent statements for all of the Understanding docs

Chuck: "people can use different input modalities" - rather than devices

<jon_avila> Modalities is fine with me but it may not understandable by some

AC: I can see that being more general than devices

<AWK_> "The intent of this Success Criterion is to ensure that people can use and switch between different input modalities when interacting with web content"

<AWK_> ""The intent of this Success Criterion is to ensure that people can use and switch between different modes of input when interacting with web content""

Brooks: Not sure that input modalities will be more understandable that input device

<Detlev> "different ways of providing input, such as most, keyboard, touch, or speech"

<jon_avila> mode is more understandable than modalities

LC: I thought of that - and that's why I used "devices" rather than "modalities"

<bruce_bailey> +1

<Chuck> +1

AC: "mode of inputs"

<laura> +1

<Brooks> +1

<JakeAbma> +1

<AWK_> +1

<jon_avila> +1

<Makoto_> +1

<jon_avila> auctioneer

BB: Next to last paragraph - change "doable" to "possible"

AWK: Already cleared up

RESOLUTION: Accepted as amended

RESOLUTION: Accepted Concurrent Input Mechanisms and merge 915 as amended

Changes to Understanding Orientation

<alastairc> https://github.com/w3c/wcag21/pull/916/files?utf8=%E2%9C%93&diff=split

AC: 7 reponses

Proposed version: https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/understanding_changes3/results#xq2

DF: Was just trying to take out the clause in the last part of the first paragraph

<bruce_bailey> +1 to AKW edit

<jon_avila> The specific benefit would be to fit more words on the screen when zoomed in

AWK: Mention of low vision users seems out of place because they aren't mentioned earlier (for example as dexterity users are)

AC: Don't see any other comments on this one - are there any objections to the change?
... MG suggesting changing intent

MG: We want to make it as clear as possible - in all of these intent statements
... "The intent of this Success Criterion is to ensure that content displays in the orientation (portrait or landscape) preferred by the user."

<Detlev> fine

AC: I have no objection to that - any objections from anyone else?

MG: First example referred to one specific orientation - should be either orientation
... Prepend the following to the last sentence of the example 5. "Since a piano app is emulating a physical piano keyboard that needs to retain relative physical characteristics between keys, either too few keys would be available, or the keys would be much too narrow."

AC: Crossed my mind as well

MG: You're emulating an experience which is why it's essential

AWK - you really mean replace not prepend

MG: Correct - started typing it one way and then typed out the whole thing

AC: Any other comments on Understanding Orientation?
... Need to match up with others (remove boiler plate template stuff)

<david-macdonald> several Advisory Techniques are incorporated into this Understanding document.

DMD: Small typo - need a capital S

AWK: May be paragraph we just removed

DMD: Live regions

Oops - David is working in the future - wrong SC :D

DMD: What did we decide on compounding testing - orientation with reflow etc

MG: Orientation req is that orientation is not prevented from happening. Has nothing to do with display of info

<jon_avila> operation

DMD: Current SC says w/o loss of functionality. What you're saying is what I wanted - but what you're saying...

AC: SC text actually uses the word "operation"

DMD: How will we interpret this. Folks will ask does this have to work with reflow.

AC: Could I refer you to the arguments on GitHub about that one?

DMD: I don't recall any resolution

MG: Could get tagged with needs to be revisited with Orientation

<gowerm> "Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential."

DMD: What did we say about functionality in the understanding - what does "operation" mean

KW: We added the content doesn't restrict it's view was mainly to address that we're not looking at having the user test all the scenarios, but looking rather at scenarios where authors restrict.
... so we're saying that you're not restricted from switching from portrait to landscape

DMD: If keyword is "restrict" - what you just said I'd like to copy and paste that into a paragraph in Understanding doc

<alastairc> I'd read 1st paragraph: https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html

KW: This SC has nothing to do with anything other than not restricting
... Went back and looked through the logs of what we talked about and the "operation" that we talked about was more about the operation of moving from portrait to landscape mode.

DMD: Should I just draft a paragraph on what you just said AC?

AC: Yes - that can go into the second paragraph

MG: Last week we resolved new change - then came back and made a new issue to capture what will be done - then we can finish that up later

AC: Any objection to accepting as amended the current understanding document

DMD: Yes - first sentence
... SC requires that user is not restricted

AC: Believed we changed the first sentence

AWK: Read the update

MG: My understanding David was that you were going to come up with a note about this.. anything about that would also fail reflow

<david-macdonald> Therefore, websites and applications need to support both orientations by making sure content and functionality is available in each orientation. While the order of content and method of functionality may have differences the content and functionality is available. When a particular orientation is essential, the user needs to be advised of the orientation requirements.

DMD: There are a bunch of things that can go wrong when you flip your orientation and have your reflow going on at the same time.
... Could not give consent if these two sentences are still in there

MG: Not sure I agree with that

AC: Hypothetical - if a website does not remove some functionality - something disappears if you change from landscape to portrait. It's not based on width - just based on browser detecting orientation change. Would that fail?

DMD: Are you saying that you're dropping content based on orientation?

AC: Yes

<gowerm> +1 to Alastair. If you remove content based on orientation, then you are effectively removing content for users dependent on the view, so I think you have to have language covering that.

DMD: Agree , but I haven't seen that before. Think there is more likelyhood that ... <lost it> People will be forced to look for that sort of thing in CSS

AC: 3 SCs that we need to look for ways to make testing easier. Orientation, Concurrent Input Mechanisms, (and another one) - So yes there is a sort of testing aspect, but don't believe that overlaps with Reflow

DMD: Maybe I should take an action to rework this and come back. Even among us there seems to be some confusion about what this requires. Understanding has some double-speak in it. This has huge implications

<AWK_> AWK: I agree with David, but think that we should accept the changes we have and work on further updates to accept on Thursday.

DMD: Say we would require that it doesn't restrict and that the operation is the operation of changing the orientation.

<gowerm> +1 to AWK. Adopt the latest change and assign David to rewrite to address the concerns he's expressed.

AC: OK - leave this one open and we'll come back to it on Wednesday

DMD: Yes - just to restricting orientation and to clear up operation of changing orientation

AWK: OK to accept current changes and then come back on Thursday so that we're not looking at such a big batch of changes

DMD: Feel it's such a big issue - not comfortable accepting until we get it all sorted out

AWK: Believe we'll at least get these initial changes in, but come back to these larger issues on Thursday

<gowerm> it's an iterative process. This round doesn't have to be perfect, but it should be better -- and I think this new version is.

AC: If we accept what we've got and then we have another draft we'll have something clear to look at

<laura> need to drop off the call. bye.

<jon_avila> I can if need be

<jon_avila> sure

<jon_avila> scribe: jon_avila

<gowerm> +1

RESOLUTION: Accept pull request 916 as amended (Orientation) with the understanding that further edits are needed for the "functionality" question

Motion Actuation

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/understanding_changes3/results#xq3

AC: looks like everyone is happy. 8 yes none against
... May be some editorial structure later, has anyone on the call who has not put in the survey have anything to say?
... hearing no one agreed

RESOLUTION: Accept pull request #917

Status Messages

<alastairc> https://github.com/w3c/wcag21/pull/918/files?utf8=%E2%9C%93&diff=split

AC: 1 proposed change, 6 accept. Detlev had some changes.

Detlev: some messages could be treated as status by some authors with language "could be status updates"
... Would not start with example that maybe but something clearly that is a status message.
... these were very small changes

MG: happy to address. Had originally had "would be" and someone had asked to change from "would" to "could".

AC: need something more straight forward

MG: If those things were offered in dialog box or focus may be they would not be.

<alastairc> https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html

JA: suggested being clear in example that they are not in dialog or focused

MG: Andrew make would instead of could and put in paren (assuming they do not take focus)

AC: Detlev's second one is about example that is already in paragraph above.

detlev: would be moot if we change the first thing
... Minor point -- so not pressing point about added items

AC: rather leave it as it is unless someone....

MG: Too many commas -- search "by their nature"

AC: Any other comments on this understanding document for status messages

DM: Capitalization
... talk about area of best practice we should have live link

AWK: will need to do major link scrub on lots of things

DM: Using ARIA best practices is in the example section. 3rd or 4th bullet
... 5th bullet in status message example section.

AC: should the example section be more agnostic

DM: We were thinking ARIA best practices in this case.

MG: doesn't think it needs it although won't lose sleep over it. Lot of considerations around it

DM: Do want to point to something authoritative

<alastairc> "The element is assigned a suitable role and importance."

AC: what about the element is assigned a suitable role and importance.

AWK: This is not a technique
... How do you assign importance

DM: role progressive bar is inherently live

MG: can also give relative importance
... just leave role and take out importance

https://www.w3.org/TR/wai-aria-1.1/#progressbar

AC: any other comments on status messages
... with no objections we can have resolution

DM: add failure example

AC: wouldn't a failure be reversing the success criteria?

<Zakim> AWK, you wanted to offer suggestion re failure

<alastairc> Place to add techniques for tracking: https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#List_of_Techniques

AWK: if we think we have a new idea we should add it to the wiki page. at some point we will need to go through all of these documents and turn into future link items or remove them.

RESOLUTION: Accept pull request #918 as amended

Understanding document questions

TPAC

ac: anything else that we have not covered?

TPAC dates

<AWK> https://www.w3.org/2018/10/TPAC/schedule.html

MC: Week of 22 October. AG WG has been assigned Thursday and Friday of that week

<AWK> October 25-26, 2018 - in Lyon France

MC: Is that ok? Are the overlap acceptable? Shadi doesn't want AG and Evaluation TF to overlap

<gowerm> where is it being held?

<alastairc> Lyon, France

MC: Do people want to move to Monday Tuesday?

<AWK> ARIA, Web Platform, EO, Silver, and Evaluation are Mon and Tues

AC: It is Leon France

AWK: EO, silver, and other task forces are meeting

MC: Silver does want to overlap with us.

<bruce_bailey> no preference

AWK: Do people have any preference?
... ties into another update that we have. It might be worth having more substantial amount of time to work with Silver. Such as having a morning together.
... would personally preference Monday and Tuesday

AC: Worth and email out to the group.

Silver/WCAG 2.2 update

Chuck: Talked about Silver and WCAG 2.2. Heard Silver in context of "they" and "them"

AWK: perfect tie in to next agenda topic -- Shawn and Jean as the TF co-facilitators
... with regard to Silver and AG it is all of us.

AC: we have the AG WG that is chartered. With the working group we have task forces. We also have the Silver TF which is the potential WCAG 3.0. Code named silver (AG).
... Shawn and Jean have been leading that for 18 month to work on the next big upgrade to the guidelines
... Point we are now is coming up to release of 2.1 and making that choice on how the working group as a whole will progress - potentially a 2.2 and a separate stream on silver.
... neither of which we are charted to do
... Had recent meeting to talk about how these things might work together. Silver TF have plans for next 18 month including creating first draft and getting structure together and answering key questions.
... Conversation is around how we work together

Chuck: Could they present to us before we make a decision.

AC: Not asking for a decision now. They did a presentation two weeks ago.

MC: The silver people want to do a presentation to the WG on the requirements. I told them to hold off until 2.1 goes to req so we have some brain space to focus on that. No decision is needed at this stage.

<marcjohlic> Silver Progress wiki: https://www.w3.org/WAI/GL/task-forces/silver/wiki/Progress_Updates#Silver_Update_for_4th_Quarter_2017

<marcjohlic> Silver Design Sprint report: https://www.w3.org/community/silver/draft-final-report-of-silver/

MJ: dropped in links that Shawn and Jean had shared

<alastairc> https://goo.gl/5Hczsu

<alastairc> Presentation

AC: They did a design sprint at CSUN.
... Working a requirements document. Next thing we will see after 2.1
... rather than a public working draft which we are not charted for that we do an editors draft later in the year. Still be decided.

MC: would add that the editors draft would be similar to the planned public formal working draft. They would public but more like community group reports.
... This allows them to get public review and review from the WG on what they are building so they will have a better idea when we go to get chartered

alex: Public working draft of what? 2.2 or something else

AC: We are talking about Silver. Their approach to getting to next stage of what they are working on

Alex: Output of silver and not AG WG

awk: we've had some discussion about WCAG 2.2, silver, etc. Do we need to plan on both concurrently.
... in talking with co-facilitators -- we have a lot to do with 2.1. We've had less time and we need to allow ourselves some breathing room rather than racing to WCAG 2.2.
... What we really need for what is being thought about for silver and 2.2 we need more time to work and advanced planning.
... Rather than chartering for 2.2 and chartering for Silver when we don't know exactly what that would be we would say we need to continue with current charter which goes to October 2019.
... Silver might say we need to update the conformance model, etc. or how should the guidelines be structured.
... with those things in place -- are we now ready to re-charter with the intent of having an update. Maybe two documents on parallel track or may be we are ready to make a switch. This would give us two years or maybe longer to be on an update cycle for WCAG.
... May find that there is more to do.

Alex: maybe they would lob ideas at us in the near term

BB: What type of overlap is there between the groups?

awk: Anyone who wants to be part of Silver TF can be. Challenge is that people don't have bandwidth to do everything.
... Overlap has not been tremendously large.

BN: hoping to have some opportunities to contribute to the framework of the new model after 2.1

MC: Proposals are not formal deliverables of the wg. They are incubation and don't fall under patent policy.
... Regarding input into Silver -- they want input -- they plan regular inputs to the WG and talking about increasing it.
... Hope to have good structure but won't have tons of content at that point
... structure will framework and they want to nail down structure and we will monitor in working group

ac: anyone on the WG can join the TFs

awk: we have a Silver TF that has been effect for over a year

ac: overlap will increase and have some community group participants. After charter and have Silver as deliverable we will have to update things in that regard

MJ: does that mean it's ok to drop into the Silver call from time to time.

AC: please check with Jean and Shawn first. They want people to be familar -- they don't want people to drop in dump some ideas and then leave.

<alastairc> trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

15 May 2018

Attendees

Contents

Understanding changes to review and approve: https://www.w3.org/2002/09/wbs/35422/understanding_changes3/results

Changes to Understanding Concurrent Input Mechanisms

Changes to Understanding Orientation

Motion Actuation

Status Messages

Understanding document questions

Other comments or questions on understanding documents

TPAC

TPAC dates

Silver/WCAG 2.2 update

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output