<JustineP> scribe: <JustineP.

<JustineP> scribe: <JustineP>

<JustineP> scribe: JustineP

<AWK> Chuck: Who will be at TPAC?

<AWK> AWK: I will

Katie: will be there

<JakeAbma> I go if Chuck goes

AWK: Alastair will be there

Charter update (https://raw.githack.com/w3c/wcag/charter-2019/charter.html)

WCAG 2.1 Techniques and Understanding survey (https://www.w3.org/2002/09/wbs/35422/AGWG_T_U_Aug2019/)

AWK: TOPIC: Errata, Motion actuation #733
... Split responses received
... suggestion received to revise normative text. Also some queries about what controls are being voted on.

<AWK> Text of SC: Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

AWK: 3 approvals received, 3 disapprovals received. What do people think?
... Steve, was this one of your SCs in 2.1?

Steve: You're correct. Going through historical examples, trying to decide.

AWK: Anyone else?

David: Reading through it now

<Fazio> Link says forbidden when I click

David F: Can't get to Understanding Techniques link via IRC

AWK: Remove "%22" and "end parents," re-try

David F: worked

AWK: Pull request is a substantial change to normative SC text in terms of volume of words changed. A little reluctant unless group feels that we are changing something that is incorrect. Can we clarify in Understanding doc?

Katie: Agree with AWK. SC shouldn't be changed if it can be clarified in Understanding doc

David M: Not sure what issue was. Seems that user can disable controls.

AWK: Users can accomplish motions through some other mechanism and no accidental actuation occurs

David M: In order to meet success criteria "before" and "after" statements must be met

AWK: Question is around exceptions, first in particular

David M: Exception applies to users with AT that is doing something related to motion.

David M: Is less clear than we would like though

AWK: Agree.

David M: Are we thinking about removing exception?

AWK: yes

David M: Can't think of use case that applies but removing bullet from SC is a big deal

AWK: Would instead embed exception in top content. Does supported interface exception mean author doesn't have to allow disabling of motion?

David M: Makes this feel broader. Usually AT is geared toward one type of disability and interface components are targeted toward multiple disabilities

scribe: don't think it is a solution to remove

Steve R: Seems fine as written. Exception was meant to apply to everything, not just latter half. Seems clear enough in text and can be clarified in Understanding doc

scribe: came originally from the need to operate keyboard interface. Don't want to say that all keyboard interactions disabled. Can we clarify in Understanding?

AWK: Confirm that originated from needs around operating keyboards.
... are there other cases for user supported interface that would account for exception?

<david-macdonald> David: yes now I remember that conversation about a user moves her fingers to type... need to be exception for that...

Steve R: Some examples when initially discussed that may already be supported. Trying to locate examples that were discussed.

AWK: Phrasing is strange. In most cases, exception applies to SC in general. Worry that people would say functionality that can be operated by user motion wouldn't be concerned. Focus is on motions like "shake to undo"

David M: Agree on genesis of conversation (re: users needing finger motion to type on keyboard)

AWK: Alastair will want to weigh in. Need to consider revisions to Understanding doc. Let's leave this agenda item open.

RESOLUTION: leave open

Errata, glossary definition for "images of text" #264

AWK: Request is changing a note related 2.0 SC. (Provided summary of change.) Change is to normative text. 2 approvals
... one approval with suggested revision. For me, there is risk with changing normative text including normative definitions. Need to be cautious.
... didn't find this one as much of a concern
... don't have complete agreement around this issue. What do we do?

David M: No strong objections to clarifying in definition. Was really focused around incidental text.

scribe: we could clarify in Understanding doc

AWK: What text is problematic?

<JF> +1 to David

David M: Unless text is focus of intended message, doesn't need to have sufficient contrast.

Katie: Seems to be appropriate for Understanding doc

AWK: What if we title exception "incidental"?

David M: might help

AWK: That's what it says now

<johnkirkwood> ha ha

AWK: Could clarify the meaning of "incidental" in Understanding

<Zakim> JF, you wanted to ask about this example: https://whimsicalwonderlandweddings.com/wp-content/uploads/2019/07/Trinity-Buoy-Wharf-Wedding-Babb-Photo-33.jpg

John F: Pasted URL as example in IRC. Image is booth setup in front of building with menu. Agree with David about clarify. Alt text would not need every detail included in image.

Chuck: Mentioned street signs before but it depends on context. Maybe we need to clarify in Understanding.

<JakeAbma> this one MUST include the street name

<JakeAbma> https://photos.google.com/photo/AF1QipNUeY0YGIKQ1mf_UP93H_Ku59wUF2vCrsS3azqb

<JakeAbma> as part of the clue for sending this one, the name has specific value

AWK: Images of text has exception for incidental. Proposal received creates a bit of a loop.

<johnkirkwood> good point andrew

<JakeAbma> correction: https://photos.app.goo.gl/RRVxMLazNqYLocVs8

<johnkirkwood> maybe the exceptions should be. can we say photograph instead of picture?

AWK: definition is clear right now. Worth clarifying though about incidental text.

<Chuck> +1

AWK: rejecting the pull request makes sense but clarifying in Understanding also makes sense

Katie: Agree

<johnkirkwood> +1

<david-macdonald> +1

+1

<JakeAbma> +1

AWK: Does anyone disagree with rejecting pull request?
... and clarifying in Understanding doc?

<AWK> Need to clarify about incidental text in images in the understanding document (https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html)

RESOLUTION: Clarify in Understanding doc 143. Reject pull request 777.

AWK: Jake and John pasted in examples. May not have rights to Jake's example.

Jake: (pointed out second example)

Failure of Success Criterion 4.1.3: Status Messages #853

AWK: Only response came from me. Editorial responses commented on. Anyone else familiar with failure?
... Failure discusses what constitutes status message, role of ARIA attributes, example given.
... overview is straightforward and gives core use case
... let's leave open and leave on next week's survey

RESOLUTION: leave open
... and put on survey for next week!

Updating Understanding 1.4.11 Text Spacing #860

AWK: (summarized and provided overview) SC needs clarification in Understanding doc.
... I commented with approval including editorial changes
... any additional questions/comments?
... any objections to accepting as amended (minor editorial change)?

<Chuck> +1 no objections

RESOLUTION: accepted as amended

<AWK> AWK needs to add an apostrophe on line 17

Adding extra paragraph to F94 for issue 854 #863

AWK: 2 approvals and no other responses
... (summarized issue) wonder if we want to suggest change to title

<Detlev> +1 to change of title

AWK: or leave as is. Either way, is ruled by procedure.
... any thoughts?

Detlev: change would be good. Can be combined with other measurements.

AWK: any objections to changing title?

<JF> No

<AWK> Change title from "Failure of Success Criterion 1.4.4 due to text sized in viewport units" to "Failure of Success Criterion 1.4.4 due to incorrect use of viewport units to resize text"

RESOLUTION: accepted as amended

<Detlev> go on then

<Detlev> scribe: Detlev

Charter update (https://raw.githack.com/w3c/wcag/charter-2019/charter.html)

AWK: Charter has gone through member heads-up review - not official
... look at the charter - the chairs don't receive all the comments
... comments may come from W3C management

<AWK> phne hung up - brb

<AWK> https://raw.githack.com/w3c/wcag/charter-2019/charter.html

<JF> https://raw.githubusercontent.com/w3c/wcag/charter-2019/charter.html

AWK: There have been edits to charter as a result - some simple (changes to team contacts, external funds etc.)
... Some people with limited involvement in group
... biggest concerns were around Silver - does it apply to stuff beyond the web, AR / VR, new UA requirements, AT req. etc
... we have UAAG ATAG under out umbrella - clarified that in Silver we do talk about web content - may be applicable beyound that but we do not impose req. for UA / browsers
... some people thought it should be tech-agnostic - software handled via WCAG2ICT

AWK (looking for version prior to Michael's update)

<Zakim> JF, you wanted to note that the URL isn't working

JF: AWK you state that Silver TF not working on hardware / non-web - the TF itself may not be aware of that
... timeline seems overly aggressive - unrealistic timeline
... unlikely to be ready by Nov '22
... that's Deque's view

AWK: Silver TF is aware that they are working on web (I think)
... normative guidance will be on content

<JakeAbma> Good question! From the Silver Requirements, I think we have this described as clearly as we currently can in these particular sections: Design principle 3: Be flexible enough to support the needs of people with disabilities and keep up with emerging technologies. The information structure allows guidance to be added or removed. Requirement 4: Technology Neutral Guidance should be expressed in generic terms so that they may apply to more than one platform o[CUT]

Jake: Asked the same question addressed to Shawn, responded - seems the opposite of what AWK just stated
... Different views of scope of Silver - there seem to be different views right now
... reading Shawns answe (quoted above)
... Shawn's answer mentions browsers, other digital assets
... seems to say basically "we try to include everything" - so is it web only, or beyond that?

<JakeAbma> Good question! From the Silver Requirements, I think we have this described as clearly as we currently can in these particular sections:

<JakeAbma> Design principle 3: Be flexible enough to support the needs of people with disabilities and keep up with emerging technologies. The information structure allows guidance to be added or removed.

AWK: In Silver requirement include advice beyond web content (UA, AT, OSs etc) - but this is not the core guidelines

<JakeAbma> Requirement 4: Technology Neutral Guidance should be expressed in generic terms so that they may apply to more than one platform or technology. The intent of technology-neutral wording is to provide the opportunity to apply the core guidelines to current and emerging technology, even if specific technical advice doesn't yet exist.

<JakeAbma> Requirement 8: Scope The guidelines provide guidance for people and organizations that produce digital assets and technology of varying size and complexity. Our intent is to provide guidance for a diverse group of stakeholders including content creators, browsers, authoring tools, assistive technologies, and more.

AWK: There is bullet on emerging tech - the scope as far as W3C is concerned is emerging tech *on the web* - this has been going on for a while
... W3C currently has discussions arounf this - but so far there is no agreement to extend the scope
... we could extend scope tp software but feedback so far suggests to be careful, charter may nit be approved

Jake: Should we have a discussion around that then with Jeanne and Shawn? I'm not the only one wondering - MATF decided nit to open Pandora's box on native field

<JF> +1 to Jake

AWK: This discussion has happened but that may not have been conveyed clearly

JF: Just note that tree regulars are uncertain about status - so it is not trickling down right now

<AWK> AWK will talk with MC/AC and Jeanne and Shawn to ensure this is clarified for the TF

AWK: Will talk with Alastair and Michael to get more clarity
... third bullet in Charter text (reads out text)

<AWK> Develop Silver (provisional name) to succeed WCAG 2.x. The goal is to provide information that can be used to improve the accessibility of products when using the guidelines on a variety of platforms, without writing normative requirements for the platforms themselves. As noted in the Requirements for Silver, it will use a different framework to allow it to address more disability needs, address emerging technologies on the web such as augmented / virtual

<AWK> reality (AR/VR/XR) and digital assistants, and provide support (for instance, through supporting techniques) for authoring tools and user agents, and non-normative support for technologies that impact accessibility such as digital content and applications, assistive technologies, software and web applications, and operating systems. This will require development of a new conformance model, engaging policy makers in that process, and testing the model with

<AWK> policy makers from different settings.

<AWK> Note "on the web" before emerging technologies

<AWK> and note "non-normative" before technologies that impact accessibility

AWK: these changes were done to clarify the scope (web is focus)

<JakeAbma> https://w3c.github.io/silver/requirements/

Jake: reading part of scope - requirement reads that Silver will include software (incl. mobile apps)

<JakeAbma> "Silver will have a broader scope than WCAG 2.0 and 2.1. The Web Content Accessibility Guidelines (WCAG) are scoped to Web and to Content. Silver is being designed to be able to include:"

<JakeAbma> software and web applications, including mobile apps

AWK: is this the requirement doc?

Jake: this is the link that Shawn send recently
... Silver requirement link, apparently

AWK: It could be clearer, the separation between core guidelines (web) and advice (beyond web)
... it is a little confusing but consistent with what is in the charter - agree?

Jake: If we have a discussion now about that after all this time, it indicates that it should be clearer

<JF> me/ gotta drop, bye all

Chuck: Agrees with Jake that thereis some confusion - understanding was that guidelines are qwritten for the web but in a way that it is extensible

Jake: That was the position already - there is a lot to add if things beyond web should be added - should be clear that the scope is web / web content, it is nti clear from the current requirements for Silver

AWK: Agree Jake that scope should be limited to web?

Shaould be wider from a user perspective but W3C is focused on web, so this is what counts

AWK: Member organisations can weigh in and suggest scope should be extended beyond web

Jake: it is weird that web is covered on phone but not some native app - so from users perspective it should open up

AWK: Other thoughts?
... Think there are 2 things: 1. what we do in the charter, strict interpretation, 2. we can still make an effort to do that in a way that can be applied more broadly
... if we define somwething that can be applied to native apps this is fine

<johnkirkwood> why do we define native applications as beyond the web? is VR in a browser the web?

AWK: even if we define perfect guidelines that does not preclude whether they are turned into legal requirements
... so to some degree ou trscope can be broader, but no way to control what happens afte rthat
... VR in the browser is web content, like a PDF displayed in the browser

<johnkirkwood> so anything that renders through a web browser ok

AWK: Native app would be beyond web - some areas see cross-over, as when PDF in browser counts as web content while opened up in Acrobat it os no longer web content

<johnkirkwood> so anything that goes through a brwser is the web.

AWK: institutions need that clarification to draw the line between what is in and out of scope

<Chuck> +1 to conditional approval

AWK: Are people comfortable with the charter then?`

<johnkirkwood> +1

Chuck: provided that other communication clear sup the current confusion

<AWK> "Conditional approval" means we need to clear up the sources of confusion with silver and the scope

AWK: Other questions / thoughts?
... So this will move forward with an official charter approval process via member companies
... members might suggest improvements

Jake: Will we gwet update regarding communications with Shawn / Jeanne if there are updates to the text?

AW: Absolutely

AWK: Jeanne, Shawn, Michael may believe that the charter is basically fine with small changes, or not - will update group on discussion
... Any other questions?
... thionk about it, if you have issues, send a note

John K: Wants to have clarity on the proper language that is voted on by member companies (?)

AWK: WG members who are with member companies, advisory committee members give support (or not), or support with changes, only if there are these changes, etc. If you are on a member company, just help them to understand what is going on with the charter.
... If people on the WG disagree we should discuss it here and now, not wait until the formal approval process

WCAG 2.2 discussion

AWK: Use a few minutes to run through 2.2 SC - raise awareness if you have problems

<AWK> Detlev: unclear what will happen with dragging SC proposal

<AWK> ... from MATF

<AWK> ... no one else listed to collaborate on it. There is a draft, but not much in the way of comments

<AWK> ... please look and provide feedback

<AWK> ... changes the scope of 2.5.1 Pointer gestures

<AWK> ... if questions, ask Detlev

AWK: basic idea of SC 2.2 dragging proposal is to include things like slider without directional constraints also has a single point operable alternative
... Any other 2.2 SC items you wantr to discuss?
... Accessible Authentication has been sent out

David F: Has sent out a draft for "Not relying on user memory"

AWK: Was that sent to just a few people? Is the link to Google docs available? Was it sent to whole group?

David F: No - but feel free to distribute

<JakeAbma> https://docs.google.com/document/d/1NEDLUWt_VFKtdHhcgm4j-ssWguSGeY8fhdSxm_41WzU/edit

<AWK> "Functionality available in different orientations"

Jake: SC "Functionality available at both orientiations" - there is a draft, there will be a small discussion on Thursday - see link above

AWK: This is to add to 2.1 Orientation which forbids restriction of orientation, this is looking at *equivalent* info in both orientations
... Would love to finish off Failure Techs so we do not need to talk abou them at TPAC

Trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/(quited above)/(quoted above)/
Default Present: AWK, Detlev, Fazio, Chuck, SteveRepsher, JakeAbma, david-macdonald, JF, johnkirkwood

WARNING: Replacing previous Present list. (Old list: AlastairC, AWK, Fazio, Raf, Jennie, JustineP, MichaelC, johnkirkwood, Laura, KimD, jon_avila, david-macdonald, Rachael)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK

Present: AWK Detlev Fazio Chuck SteveRepsher JakeAbma david-macdonald JF johnkirkwood
Regrets: Bruce Rachael Nicaise Laura
Found Scribe: &lt;JustineP.
Found Scribe: &lt;JustineP&gt;
Found Scribe: JustineP
Inferring ScribeNick: JustineP
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Scribes: &lt;JustineP., &lt;JustineP&gt;, JustineP, Detlev
ScribeNicks: JustineP, Detlev

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 20 Aug 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)