Accessibility Guidelines Working Group Teleconference -- 21 Nov 2017

<AWK> trackbot, start meteing

<trackbot> Sorry, AWK, I don't understand 'trackbot, start meteing'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<AWK> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 21 November 2017

<AWK> +AWK

<AWK> Chair: Joshue

<scribe> scribe:bruce

<JakeAbma> Scribe JakeAbma

<JakeAbma> scribe: JakeAbma

zakim: next item

Target Size https://www.w3.org/2002/09/wbs/35422/resolving_target_size/results

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

<AWK> +AlexLi

<AWK> +Glenda

<bruce_bailey> Jake (from survey): Looking for something like… Text Links - The target is a text link with a size that is at least 22 by 22 CSS pixels OR contains at least [x] characters…

<AWK> +Jan_McSorley

<AWK> +Lisa

<AWK> +MikeGower

<AWK> +Roy

<AWK> AWK would like to hear KimD on this

SteveR: difficult to get it stronger than we have now, sadly
... solution = to get back OR perhaps like user agent control exception

Kim: really difficult for companies with footnotes or math equations for text links

<kirkwood> +1 to the footnotes point

Kim: sure a lot of value in intent but we need to exempt

<Zakim> AWK, you wanted to say that we might exempt text links in blocks of text at AA and then include them at AAA

AWK: one option: exempt in blocks of text, add it to AAA

<Joshue108> That could be inline links, or a part of a Math equation, citation or subscript

AWK: maybe increase size of links option (content/UA?), difficult to specify

Josh: exempting certain parts, to be defined…

<AWK> TPAC: There were lots of issues raised about the existing language

Detlev: what led to this simplification at TPAC?

<Detlev> ok thanks

AWK: tried to put all issues in place and came up with this solution

Josh: define some exception, take some time for another iteration…

Detlev: re-introduce inline instead of text links as an exception?

<kirkwood> if inline excemption include footnotes? if so yes, seems like a good idea

<Kathy> Inline: The target is in a block of text.

Kim: not sure what block of text is, does it solve math equations?

<AWK> blocks of text: more than one sentence of text (WCAG 2.0 glossary)

Kim: going back to old text doesn’t solve this further

<Glenda> should we wait until Kathy Wahlbin is available to discuss Target Size. I think it is hard to discuss a proposed SC when the SC manager is not in the mtg.

<laura> blocks of text: more than one sentence of text https://www.w3.org/TR/WCAG20/#blockstextdef

Steve: WCAG needs more when it comes to math an science
... math not really different than text, can’t fall under essential

<Detlev> @Kathy: OK, I see the point

Kathy: 44 X 44 didn’t work with lists, discussion went on, one of sizes 44x22 AA and 44x44 AAA is good starting point
... Math does fall under essential
... it all depends on essential definition
... footnotes… if they are on other page it needs to be 44x22 otherwise not needed, exempted for inline links

<Zakim> Joshue, you wanted to ask if subsript Math etc are not covered already by Essential - A particular presentation of target is essential to the information being conveyed;

<Zakim> bruce_bailey, you wanted to ask Kathy which exception covers single digit footnote?

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets

Bruce: text at survey last language for SC?

<AWK> https://www.w3.org/2002/09/wbs/35422/resolving_target_size/results

<bruce_bailey> User Agent Control - The appearance of the target is determined by the user agent and is not modified by the author

<bruce_bailey> Essential - A particular presentation of target is essential to the information being conveyed

<bruce_bailey> Text Links - The target is a text link with a size that is at least 22 pixels in width or height;

AWK: if too much is lost after TPAC maybe we need to do something about text links as there are still issues

MGower: we try to emulate mobile design guidelines, can we try to come up with other options to solve the problem for web?

<bruce_bailey> +1 to what MikeG is saying about text links being UI elements rather than ordinary hypertext

<laura> Role?

MGower: links in primitive meaning is text reference to other document. Links often wrongly used so can we fix this issue by adding to the SC the emulation of for instance buttons?

<bruce_bailey> inline hypertext is as old as the web

<KimD> *I was thinking the same thing, Rachael!

<Zakim> bruce_bailey, you wanted to say survey phrasing is okay for text menus, but not endnote style links

Kathy: doesn’t agree to exclude hyper links

<Zakim> Joshue, you wanted to ask if we should document the SC iterations and path to certain exemptions

Bruce: footnotes need exemptions, but not hyper text in general

Josh: not hearing consensus on this issue
... anyone want to draw up a list for exemptions?

Kathy: maybe put in a couple of exemptions from before

<Kathy> The size of the target for pointer inputs is at least 44 by 22 CSS pixels except when: • Essential - A presentation of target is essential to the information being conveyed; • Equivalent - The target is available through an equivalent link or control on the same page that is at least 44 by 22 CSS pixels; • In-Page - The target is a text link where the destination is on the same page; • Text Links - The target is a text link with a size that is at least 22[CUT]

<Kathy> in width or height; • User Agent Control - The appearance of the target is determined by the user agent and is not modified by the author.

Josh: whats the difference here?

Kathy: Equivalent + essential gives more space in ways

<KimD> "essential" = if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

Steve: essential does not cover math equations

Kathy: define a new term for this?

<laura> essential def: https://www.w3.org/TR/WCAG20/#essentialdef

<Kathy> • Required - A presentation of target is required to the information being conveyed;

<bruce_bailey> -1 to trying to define "required"

<laura> blocks of text more than one sentence of text https://www.w3.org/TR/WCAG20/#blockstextdef

Josh: we have no consensus now

<AWK> I added Kathy's latest suggestion to the wiki page: https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets - other possible improvements can be added to this wiki page.

RESOLUTION: leave open

Purpose of Controls

<Zakim> JF, you wanted to kick this off

<Joshue108> https://www.w3.org/TR/WCAG21/#purpose-of-controls

JF: this SC is tricky

<Joshue108> https://github.com/w3c/wcag21/issues/6

JF: fixed list of terms of common elements and attach meta data for allowing repurpose or expend purposeful people

<Joshue108> do we have any up to date understanding documentation for this one?

JF: first thing I did = split form inputs / tokens

<gowerm> My last suggestion for SC language: In content implemented using markup languages, user interface components that serve a conventional purpose can be programmatically determined.

JF: started with auto-complete tokens, around 51/52, they are well know and used by UA already
... the other UICs there the it gets a bit blurry

<laura> Understanding doc: http://rawgit.com/w3c/wcag21/purpose-of-controls/understanding/21/purpose-of-controls.html

<Joshue108> Thanks Lisa

JF: links vs buttons etc. tried to split them on function
... on basis of function the UIC need to be tagged
... filtered critical vs importants, lots are critical (personal take on it)
... but we need a fixed list, 50 + 60 in total is a lot
... specifically for the normative SC
... need to map terms to meta data schemas out there
... we need more than one vocabulary library to point to
... last piece of puzzle is to show we do something with it

<gowerm> Here's my suggestion: In content implemented using markup languages, user interface components that serve a conventional purpose can be programmatically determined.

<gowerm> User Interface components is a defined term

<gowerm> we would define "conventional purpose"

<Lisa_> bruce , it is a technique.

<Lisa_> it is suffient

<Lisa_> understanding https://rawgit.com/w3c/wcag21/purpose-of-controls/understanding/21/purpose-of-controls.html

Lisa: in comments lots of questions about techniques

<Lisa_> https://docs.google.com/document/d/1Ixl5kpoi2D5oq_vU7iSbERpYpDv6RmA0e42Os486d3I/edit#

Lisa: yes we have techniques already

<Lisa_> family-name familyName

<Joshue108> It seems to me that the current SC text gives no indication of its relation to the use of semantics metadata and personlisation.

Lisa: list must be made consistent
... auto-complete is a sufficient technique

<Joshue108> Also the language seems to be saying - just use HTML properly or echo 1.3.1 not evolve it.

<Lisa_> Note that some of these terms are at risk. Any term will be removed before leaving CR if it does not meet all the WCAG exit criteria

<Joshue108> +1 to Mike

Josh: we need proper SC wording first

<Lisa_> issues 1. any issues with sc text. 2.where to put the table

<JF> 1) Finalize language, 2) Form inputs and token list, 3) Review list of UICs, 4) Discuss Techniques

MGower: before talking about techniques etc. please get SC wording in place first

<Zakim> gowerm, you wanted to say here is my proposed wording for the SC In content implemented using markup languages, user interface components that serve a conventional purpose can be

<alastairc> JF, you said there was one thing missing from Mike's text, but I missed what it was, could you mention that please?

<Ryladog> Present

<JF> @alastair, it needs to be more than just programmatically determined, it also needs to be 'actionable' - i.e. that something useful can happen from the annotation of metadata

<Lisa_> =1

<Lisa_> +1

<alastairc> hmm, ok, I thought if metadata was attached, that would be actionable (with a UA extension)

AWK: problem is that a list will grow for conventional purposes

<Lisa_> yes, that is what we mean

AWK: correction...problem is that a list will grow for conventional controls

<Lisa_> +1

<JF> 1) Finalize language, 2) Form inputs and token list, 3) Review list of UICs, 4) Discuss Techniques

JF: we need fixed list UI controls, we can then add meta data to it
... it / controls also needs value for it because everything can be programmatically determined

<alastairc> Wouldn't that actionable purpose come from defining the 'conventional purpose'? I.e. list of conventional 'things'.

JF: we started with this list for AA so people can get used to using meta data

<Zakim> Joshue, you wanted to ask how and why this is different from 4.1.2 or 1.3.1 needs to be established

<AWK> In content implemented using markup languages, user interface components that serve the following conventional purposes can be programmatically identified: Names: Full, first, last, additional/middle, family, and nickname Address information: Street address, state, province, region, country, postal code Contact information: ……

<alastairc> Joshue - neither 4.1.2 or 1.3.1 apply to 'purpose', the role could be the same for multiple inputs, but the purpose is different.

Josh: it needs to be different from 1.3.1 / 4.1.2
... so can’t use the meta data wording

<Zakim> MichaelC, you wanted to say high-level definition in SC or definition; specifics outside the guidelines and to say metadata vs properties

<gowerm> "conventional purpose" is the term to be defined.

MC: see the need of terms but NOT in the guidelines

<Lisa_> In content implemented using markup languages, user interface components that serve the following conventional purposes, the purose can be programmatically identified:

MC: the big long list is too much for guidelines

<Lisa_> In content implemented using markup languages, user interface components that serve the following conventional purposes, the purpose can be programmatically identified:

MC: rough definition would be OK, then in techniques or understanding

<gowerm> +1 to Michael's concern about the list being normative, and trying to think out other ways of incorporating

MC: meta data is not the proper name we should use here, serves different purpose

<Glenda> +1 to we do not want a repeat of the mush that is 1.3.1

<MichaelC> +1 to clearly defined, -1 to in the guidelines

<alastairc> I agree the list needs to be clearly defined, neutral on where it is so long as people are happy that it applies.

JF: don’t agree with NOT adding it to SC, it does need to be a defined list so every one knows what is expected

<Joshue108> +1 to Lisa

<Lisa_> In content implemented using markup languages, user interface components that serve the following conventional purposes, the purpose can be programmatically identified:

Lisa: meta data should be attributes so it’s cleat for what we can use it

<alastairc> Lisa: Metadata is any data about data, so all attributes on HTML tags are metadata.

<Lisa_> In content implemented using markup languages, user interface components that serve a conventional purposes, the purpose can be programmatically identified:

<Joshue108> @alastair, dont know if I agree - they are attributes of.

<JF> +1 the list needs to be normative

<gowerm> +1 Lisa's change is an improvement

<alastairc> @Joshue108, that's just the definition of metadata, if you're not sure then probably not a good term to include in SC text.

<Lisa_> In content implemented using markup languages, user interface components that serve a conventional purposes, the purpose can be programmatically identifable

<Ryladog> +1 to this langauge

<gowerm> +1 but we still have to define "conventional purpose"

<Lisa_> yup

<AWK> I want to be able to speak to this

<AWK> that's why on queue

<JF> @gowerm AND to the list of UICs

<Glenda> +1 to this language with a minor edit

<kirkwood> +1

<bruce_bailey> +1 but again need to see definition for conventional purpose

<alastairc> Grammar check: In content implemented using markup languages, for user interface components that serve a _conventional_purpose_, the purpose is programmatically identifiable.

<Lisa_> glenda, can you put the edit in

<JF> +1 steve

<Lisa_> i like programmatically identifiable.

<Joshue108> @alastair yeah - exactly

<Glenda> @alastiarc got it!

<Lisa_> great

<bruce_bailey> -1 to "programmatically identifiable"

<JF> This may not actually need "Assistive Technology" per-se - a browser extension could suffice for some users

<JF> Oo Oo... I want to speak to that too Steve

Steve: about the list, prefer to move this to appendix or something like that

<alastairc> simpler version: In content implemented using markup languages, user interface components that serve a _conventional_purpose_ are programmatically identifiable.

<Lisa_> like the appendix, we can also update it faster

<Lisa_> like the appendix, we can also update it faster to update

<Glenda> Agree - this SC is not “Assitive Technology” dependent. Programmatically identifiable can be leveraged with a simple browser extension.

<JF> @AWK - bingo!

AWK: doesn’t like long list in the spec, but don’t see way around it

<alastairc> I don't see a way around it either, we need an accessibility-oriented sub-set of all possible meta-data.

<Glenda> I agree that the metadata for this SC been added into a WCAG 2.1 appendix (static list)

AWK: list is large, but someone needs to know when it’s done when developing

<Glenda> A normative appendix

AWK: if we have the list we can loose the ‘conventional’ part

<Lisa_> alastaircs version: In content implemented using markup languages, user interface components that serve a _conventional_purpose_ are programmatically identifiable.

AWK: if we have a list (reasonable list) we can point to the list, conventional not needed, “here’s the list”

<Zakim> JF, you wanted to talk about a normative list and strategies there

JF: we need a sub-directory for the TR space

<Joshue108> I still want to do a straw poll on text for this SC *before* we get lost in the weeds of how to do it

JF: a place where we can store these kind of lists, more working groups feel like they need a space like this
... where can we put the list?

<steverep> @JF, I view browser extensions as assistive technology as well (e.g. ChromeVOX, Stylish, etc.) - there's no hard line AT must be traditionally installed s/w

JF: publish maybe as stand alone document like a normative reference…
... instead of in the glossary

<Zakim> Joshue, you wanted to say distinctions between metadata vs element property are interesting and need to be addressed

<AWK> Scribe: Bruce

<MichaelC> scribeNick: bruce_bailey

Josh: need to be care with use of term "metadata"

something that is data versus attributes or properties of elements

<Lisa_> alastaircs version: In content implemented using markup languages, user interface components that serve a _conventional_purpose_ are programmatically identifiable.

Josh: I want a straw poll on lisa's text, get us at least half way there

<AWK> +1 to Michael

<AWK> PD = "determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities"

JF: why is PI not good enough?

<alastairc> No worries: In content implemented using markup languages, user interface components that serve a _conventional_purpose_ can be programmatically determined.

Josh: Thinks we need to stick with PD
... PI will not fly

<Lisa_> iether is fine with me. I dont think it mater

<Lisa_> maters.

<alastairc> (I think I just went with identifiable from the previous grammar.)

Katie: agree, metadata not right term here
... likes look up list, needs to be updateable

<Glenda> I think the metadata list needs to be static for compliance purposes.

<JakeAbma> Katie: the list needs to be updatable / external

<JF> but the list also needs to be normative

<jimal_> would this "meta data" be better in HTML as a 'purpose' attribute, much like <input type="email'> that changes keyboards on devices?

<Glenda> We can not change the “finish line"

Katie: HTML 5 has new concepts like pan and zoom that we want to pick up as HTML 5 evolves

<Lisa_> aria is a markup

Katie: good SC, but needs external list

<Lisa_> is used in markup

<Joshue108> In content implemented using markup languages, user interface components that serve a _conventional_purpose_ can be programmatically determined.

Josh: we are due for break

<gowerm> +1

<Lisa_> +1

<Rachael> +1

<Ryladog> +1

<JF> +0

<alastairc> +1

<Joshue108> +1

<laura> +1

<KimD> +0

<steverep> -1... the purpose, not the component, needs to be programmatically determinable

<Alex_> +1

<Makoto> +0

<JakeAbma> +1

<Detlev> +0 still uneasy about that as general AA requirement

<Brooks> +0

Josh: trying straw polls

<Lisa_> alastaircs version: In content implemented using markup languages, user interface components that serve a _conventional_purpose_ are programmatically determined

<Glenda> +0 (I prefered programmatically identifiable)

<Lisa_> In content implemented using markup languages, user interface components that serve a _conventional_purpose_ are programmatically determined

<alastairc> In content implemented using markup languages, the purpose of user interface components that serve a _conventional_purpose_ is programmatically determined.

<Lisa_> In content implemented using markup languages, for user interface components that serve a _conventional_purposuse, the purpose can be programmatically determined

<AWK> +1

<alastairc> (Less commas ;-)

<Joshue108> FINAL: In content implemented using markup languages, the purpose of user interface components that serve a _conventional_purpose_ is programmatically determined.

<kirkwood> +1

<Lisa_> right

<Ryladog> +1

<MichaelC> +1

<alastairc> +1

<Joshue108> +1

<gowerm> +1, yep

<JakeAbma> +1

<Lisa_> +1

<laura> +1

<Greg> That should be "can be programmatically determined", using "can be" not "is".

<JF> +0

<Glenda> +0 (preferred “programmatically identified” but chan live with “programmatically determined”)

<KimD> +0 (fundamental questions with SC)

<Joshue108> TOTES FINAL: In content implemented using markup languages, the purpose of user interface components that serve a _conventional_purpose_ can be programmatically determined.

<Makoto> +0 (can live with it though)

<Detlev> +0

<steverep> Can't vote, please read

<Kathy> +0

<Brooks> +0 (questions about security implications of requiring programmatically determinable controls)

<Glenda> +1 (prefer “programmatically identified” but can live with “programmatically determined”)

<Ryladog> +1

<steverep> +1 with note it must be explained in Understanding which AT is targeted

<gowerm> +1

<KimD> +0

RESOLUTION: Accept SC in principle

<Lisa_> +1

<Lisa_> conventional_purpose: widely recognized purpose. Control types are documented as widely recognized can be found at appendix XX

Josh: Still need definition for "conventional purpose"

<Zakim> MichaelC, you wanted to say I cannot live with long lists in SC or definitions - makes the guidelines as a whole too hard to use; I can live with long list in appendix; I prefer

<Joshue108> +1 to Michael

MichaelC: List cannot be in SC or glossary

<gowerm> +1 to michael's comment, and I have more to say on the list

<Lisa_> +1 tp michael

<Ryladog> +1 to MC

MichaelC: List could be appendix or Understanding

<kirkwood> +1 to MC

<Zakim> JF, you wanted to share the google spreadsheet

<alastairc> Brooks: I think there is a security review in the process, but I doubt there would be a problem. It isn't giving anything away that is not clear from the visual interface.

MC: Very close to making guidance doc normative...

JF: Believes that list needs to be normative
... Where list lives is open, but needs to be measurable and not a moving target

<Detlev> I'll be off with the break - sorry.

<Glenda> appendix!

<alastairc> the list of 'purposes' should be normative, the exact meta-data should be separate.

MC: agrees that list could be (though not my preference) normative and stable

<JF> @Brooks, we can discuss this after the break

Brooks: Asking about security, and autocomplete on financial forms

<Lisa_> definite of conventional purpose: widely recognized purpose. Control types are documented as widely recognized can be found at appendix XX

Josh no, JF yes

See everyone in 10 minutes

<AWK> Resuming the call at 1pm Eastern

<Alex_> the break is 10 min?

<AWK> Resuming the call at 1pm Eastern

<laura> 30 Second Timer With Jeopardy Thinking Music: https://www.youtube.com/watch?v=73tGe3JE5IU

<Joshue108> Have a nice night alastair!

<AWK_> resuming in <5 minutes

<Lisa_> lol

<AWK_> resuming in <2 minutes

<AWK_> resuming in <1 minute

<Lisa_> definite of conventional purpose: widely recognized purpose. Control types are documented as having widely recognized purpose can be found at appendix XX

AWK: We are back
... taking over chair

<Lisa_> a bit of a pardox "is everyone here"

AWK: SC language is close, but we still have core questions

Where a list might go? What would be on that list? Are we the right group to make that list?

<Zakim> Lisa_, you wanted to ask if we can have updates to an apendix some how

AWK: Can that list change? How does the list change effect conformance with 2.1?

<Zakim> JF, you wanted to answer AWK's second question

Lisa: If in appendix, can we link its updating schedule to work we do?

JF: No, does not thinks so. Cite at publishing would have to be to date certain version.
... If we post dot release, list could then be updated as well

<Zakim> MichaelC, you wanted to address changing list

JF: updates to list need to be normative and "carved in stone"

<Lisa_> maybe we can make a 2.1.1

<Rachael> Can we create a "working list" in understanding that supplements a formal list?

MichaelC: Any normative location needs formal update cycle

<Zakim> gowerm, you wanted to say that we need to understand the ramifications of what we're saying with this proposed list, and then ask some hard questions

MichaelC: list cannot change except by updating Guidelines

<KimD> +1 to Mike

MikeG: JF and others describe list as "wish list" or maybe just a starter set
... This is a big concern
... SC for characteristics might be similar, no need in text for exhaustive list of what are sensory characteristics, just a few examples

So we have an example SC already with an undefined set

MikeG: IBM made the decision to flesh out our own list
... It scares me to make up a list which might not be good enough

<Lisa_> definite of conventional purpose: Control types are documented as having widely recognized purpose.

Katie: similar concern, might need initially be limited to all controls listed in HTML 5 for example
... would rather have list in Understanding
... this compares to 1.3.1
... Techniques associated with 1.3.1 have gotten us through many changes in technology

Jason White: agree with katie, would like a list of characteristic that need to be PI

JW: actual list might follow from particular technology in question

<Lisa_> definite of conventional purpose: Control types are documented as having widely recognized purpose such as autocomplete or scheme.org or aria

JW: thinks we have concrete enough general language, with specifics elsewhere

<Lisa_> definite of conventional purpose: Control types are documented as having widely recognized purpose such as autocomplete, scheme.org or aria

JW: But we do not have that phrasing yet

JF: Without a fixed list, this SC cannot be tested consistently
... MikeG gave the example with sensory characteristics that IBM was compelled to come up with their own to be confident with testing results

<Lisa_> definite of conventional purpose: Control types are documented as having widely recognized purpose such as autocomplete, or aria

JF: without fixed list, too subjective

<Glenda> Core list + extended Best Practice list

Rachael: can we have two pronged approach?

<Lisa_> definite of conventional purpose: Control types are documented as having widely recognized purpose such as autocomplete, schema.org or aria such as:

<JF> +1 to Rachel - canwe look at the actual list? I believe folks can see my spreadsheet at: https://drive.google.com/file/d/0B8dsTwtY5GvmMGplTUY4UmZzX3M/view?usp=sharing

<Lisa_> definite of conventional purpose: Control types are documented as having widely recognized purpose such as autocomplete, schema.org or aria such as:

One publish list as start, but keep it open for sight owners to make up their own lists

Lisa: suggest starter minimum lists
... another example is EPUB

<JF> @lisa, extendability is covered by the AAA SC

Lisa: Normative language says "such as" so it is not an overly limiting list.
... Understanding periodically updated to include other sources for acceptable lists.

<Zakim> AWK_, you wanted to say that when standardizing a set of options it is important to identify the shared and agreed upon set.

Lisa: lots of work has gone into many of these lists
... work on autocomplete is particularly extensive

<Lisa_> we had request to make the list bigger in the comment

<Lisa_> \i dont think any of the issues opened asked for less

AWK: Building on what Rachael said, we can start with a small lists of cites
... starter list still is lengthy
... Overtime, we could add to that list. What is added to cite list is normative.

<JF> The "list" can be extended by using the AAA SC "Contextual Information" - which is wide open to everything right now

AWK: Lisa's example of ARIA or Schema.org still need to be cites to specific versions of those standards

<Lisa_> andrew can that list be in understanding? can you live with that?

Alex Li: agrees that we need well defined hard list and soft list that people could add to

<JF> +1 Alex - finite normative list is the key

<Glenda> +1 Alex

<AWK_> @lisa - ARIA and schema.org can certainly be in understanding

Alex: list is normative

<Zakim> Glenda, you wanted to compare purpose of controls to aria landmarks

<Glenda> https://drive.google.com/file/d/0B8dsTwtY5GvmMGplTUY4UmZzX3M/view

Glenda Sims: Please see this spreadsheet

Glenda: anyone concerned with concept of "conventional controls" please look at second tab in spreadsheet
... Helpful for common controls like "home".
... Asks if any of the material in spreadsheet is scary?

Glenda comfortable having list in an appendix.

<Lisa_> back to the following definite of conventional purpose: widely recognized purpose. Control types are documented as having widely recognized purpose can be found at appendix XX

<JF> https://www.w3.org/TR/html52/sec-forms.html#autofill-detail-tokens

JF: Agrees, list seems to overwhelming, but it really is okay
... Autocomplete is half the list.

JF asks if we can agree that using autocomplete tokens is important?

<Lisa_> +1

JF: If you are making a form, and using these tokens, why not a requirement to follow these conventions?
... Sheet 2: functions there are not really problematic
... Has polled taxonomy specialists at schema.org

JF asserts that this could be implemented this today, with very lightweight implications

JF: 6 / 10 / 12 common examples for common functions
... Agree that we have basic agree on SC phrasing.

<Glenda> +1 chunking the common functions into types (on sheet1 posted at https://drive.google.com/file/d/0B8dsTwtY5GvmMGplTUY4UmZzX3M/view) really helped me get to “Let’s Make This HAPPEN!"

<Lisa_> any "cant live with" it being in an apendix

JF: Key question now is can we live with the current list we have?

<Lisa_> i copied the defintions fro html5

Jason: Problem with current list is that many terms are not well defined
... HTML 5 autocomplete terms are well defined, but other terms need more examination

<JF> The list needs to be normative for this to be measurable and testable

Jason: applicability of "name" is example where use is not tightly defined
... Not satisfied with our current course since exit criteria could be satisfied by trivial examples that are not really generalizable
... Not sure how to work this all into phrasing of SC

<Lisa_> jason we had suggeste - definite of conventional purpose: Control types are documented as having widely recognized purpose such as autocomplete, schema.org or aria such as:

<Zakim> MichaelC, you wanted to say if the list is chunkable, I´d rather have the chunk categories in the guidelines and the details elsewhere

MichaelC: I heard JF say list could be chunked

MC: chucks in the GL and lists elsewhere could be okay

<jasonjgw> +1 to Michael

<JF> Chunk 1: Navigation Actions: toc (contents), next, previous, higher, lower, move

Chunks meaning "editing" rather that cite to specific list

<AWK_> -1 on the concept of chunking if it leaves open the interpretation of what an author needs to do to conform.

<JF> Chunk 2: UI / Page Actions: sign in, sign out, sign up, upload, expand, refresh, print, reset, comment, settings, date

Katie: Likes chunks and concepts like navigating rather than specific features from HTML 5 (like pan width)

<Glenda> Still need normative list for WCAG 2.1 compliance (static list). WIth an evolving soft list (for Best Practice) available to encourage moving in the right direction.

Katie: Our approach might be informed by how often we can update list. 18 months not too long to wait for updates.

<Zakim> gowerm, you wanted to say are there contradictions between HTML5 autocomplete detail tokens and other standards? Can they not co-exist, and the author references the schema in the

Katie: Prefers chunking over starter list sets.

<JF> Chunk 3: Editing Actions: open, compose, edit, cut, copy, paste, save, send, post, delete, undo, cancel

<Lisa_> i think we need to put this to survery with a ok, prefer, can live with and cant live with

MikeG: Can this be worked in as techniques where the author cross references the schema they are using?

<JF> Chunk 4: eMail Actions: Read, reply, forward (next), received, sent

MG: Does the autocomplete standard conflict with other specs?
... If we start with HTML 5 autocomplete, if I use a different spec uses something different for Name, what about resolving conflicts between the two?

<Zakim> JF, you wanted to respond to Jason - without a common fixed list anybody can use any technique and we end up with a tower of bable

MG: Author should be able to use their preferred behavior.

JF: Agrees.
... Start with "intended definitions" (from spreadsheet) and those columns can be internationalized
... If someone wants different name, namespame is one solution, but one does not have to use namespace

<JF> Chunk 5: Shopping Actions: add, remove, buy, checkout

Lisa: please do a survey on different proposals, can live with / cannot live with
... Might need different proposals today

AWK: Would like options today on the call

<JF> Chunk 6: Web Links: home, contact us, about us, our phone, our email, site map, help, chat help, services, products, terms, language, social, my profile

Lisa: Some implementations put autocomplete on the attribute and some put it in name, but tokens were consistent
... John has shared chunks, but not clear on how that translates to SC or glossary

AWK: Would like sense from people on call, (1) convenience for putting controls into one of the named chunks

<Glenda> Ooooo, I like where this is heading…this reminds me of “Name, Role, Value”

AWK: But also (2) convenient to have clear list of 51/52 items

<Glenda> Then we need the static REQUIRED list in the appendix

<Alex_> 2

<MichaelC> 1

<AWK_> 2

AKW: please vote 1 or 2

<Lisa_> 1

<jasonjgw> 1

<JF> 2 - a clear defined list

<Brooks> 1

<laura> 2

<Kathy> 2

<Glenda> 1) Chunking 9wht a static list of all the items in the Normative appendix

<KimD> chunks

<Rachael> 2

<Ryladog> 1

<Ryladog> 1 but can live with 2

AWK: do not have specific phrasing
... seeing about even split

<Lisa_> john i dont understand

JF: could have specific list and/or specific for how reference list
... could have SC language and a normative list

AWK: Agrees, but SC can make reference to appendix or other normative list, without having long list in GL

<laura> Okay with chunking if we have a static list of all the items in another normative doc.

JF: Agrees w goal.

<Kathy> yes

AWK: For people who voted (2) for the list, can you live with (1)

<JF> 3: chunked names in the SC, with a normative reference to a fully defined list

<Glenda> must have normative list of the (52) in appendix

<Lisa_> totaly confuced

<Alex_> no

<Rachael> I prefer 3 to 1 but can live with 1.

<JF> @gowerm - I agree, which is why I liked your reformulation to "UIC's"

<laura> no

<Kathy> but we need a definition somewhere

<Makoto> no, getting confused...

AWK: I would say no, because I would not know what to do.

AWK polls individuals.

<Lisa_> yes

<MichaelC> I can live with 2 *if we do the list right* not in the SC or defs

<KimD> no - I think it's too close to a spec then

AWK: For people who voted (1), can you live with (2)

<gowerm> Along the same lines as Michael.

<Brooks> no

<Lisa_> not sure what the difrence is as both seem to have a normitve list

AWK: We seem to have a bit of an impass
... some people are concerned that we writing too much of a spec
... other side feels we are not being specific enough

JF: hears concern about not getting the list right
... without a defined list, this is not sufficiently testable and a fail for us
... If we look a the chunks, I think we can get to a defined list
... The path beyond the defined list can be AAA

<MichaelC> Proposals I've heard so far:

<MichaelC> * List of terms in SC

<MichaelC> * List of terms in definition(s)

<MichaelC> * List of terms in appendix

<MichaelC> * List of terms in normative co-published companion document to WCAG 2.1

<MichaelC> * List of terms in Understanding / Techniques

<MichaelC> * Defer list of terms entirely to outside resources like Personalization Semantics, Schema.org

<MichaelC> * "Chunks" in SC and detailed list in appendix / normative reference

<MichaelC> * "Chunks" in guidelines somewhere and detailed list in Understanding / Techniques

MC: shares the option

Lisa: thinks we can do on the call

JF and AWK thinks this needs to be a survey call.

AWK: Thinks people need to think of SC as (1) chunks with pointers to other cites or (2) fairly exhaustive list

<Lisa_> epub jason,

Jason: We have experience with HTML 5 and autocomplete, but very limited experience with other technologies and other lists

<Lisa_> publishing etc

Jason: With the benefit of hindsight, a different way of dividing up the terms might have been better

<AWK_> "name" isn't on the spreadsheet's list

Jason: We had example of autocomplete and use of Name in an HR setting which obviously needs more work and consideration

<Lisa_> we have that distintion in the personlaistion tf

<JF> @Jason, the actual requirement would be for primary user's data - so at the authoring level you don't use those tokens for additional name inputs

<Zakim> steverep, you wanted to ask if accessibility support will help define the real list in the end

Jason: We need testability at same time as flexibility

SteveR: This comes down to accessibility supported for me, and we seem to need to defer

<JF> @ste3ve we need to start with a minimum list of terms

<Lisa_> what if we say

SR: We might come up with 100 terms but only can implement 25, we are going to have to come back to this SC

<Lisa_> definite of conventional purpose: Control types are documented as having widely recognized purpose such as autocomplete, or aria such as:

SR: Implementation attempts will inform our list.

<AWK_> @JF is the list on the second page of the spreadsheet the current set in total?

Lisa: Asks people to be flexible. We go to wording on basic concept of SC.

<AWK_> @JF eg is name/address info on the list?

<JF> @AWK minus the 52 autocomplete tokens at https://www.w3.org/TR/html52/sec-forms.html#autofill-detail-tokens

Lisa: Autocomplete or ARIA could be examples of being sufficient

<JF> (where ARIA = Personalization Semantics)

Lisa: These other specs might be at CR at the same time as 2.1
... We could ask Personalization (sp) task force to commit to stability of their terms

<Zakim> JF, you wanted to ask the WG to look at the spreadsheet carefully - can we start with the "understood definitions".

Lisa: We have three stable sources (autocomplete, ARIA, Personalization TF).

JF: Personalization is just one way.

<Lisa_> not saying it is a technique, it just suplies the list

<Lisa_> agreed no contradicition

JF: We have different ways of sufficient techniques

<JF> https://drive.google.com/file/d/0B8dsTwtY5GvmMGplTUY4UmZzX3M/view

JF: Still need a minimum list of controls affected

Are these terms sufficient?

Is this list too long? If so, what should be cut?

<Zakim> MichaelC, you wanted to say status of spec doesn´t matter, status of a11y support matters and to say we cannot make demands of another WG or attempt to calcify their spec

AWK: Will work with JF on survey for this issue.

MC: We should not care what the status is of other spec
... We need to focus on accessibility support

<JF> RE: Accessibility support: currently the @autocomplete token values appear to be fully supported in all browsers

MC: We cannot ask other TF to commit to no changes on list

AWK: We are at end of time today

<JF> Re: all of the other terms - we currently have a chicken and egg problem: we need a list to measure implementability and accessibility support

Next call is next Monday, four hours

We have a path to move forward

We lost time on Device Sensors today

RESOLUTION: Leave Open

trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

21 Nov 2017

Attendees

Contents

Target Size https://www.w3.org/2002/09/wbs/35422/resolving_target_size/results

Purpose of Controls

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output