Accessibility Guidelines Working Group Teleconference -- 29 Nov 2017

<Joshue108> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 29 November 2017

<Rachael> scribe: Rachael

Joshue: Yesterday covered a number of topics. We left off working on accessible auhtentication

AWK: Purpose of controls first.

Purpose of Controls https://www.w3.org/2002/09/wbs/35422/resolving_purpose_of_controls/results

Joshue: This is COGA. There is a new version.

<Joshue108> Original text In content implemented using markup languages, the conventional name of conventional form fields, conventional buttons or controls, or conventional links can be programmatically determined.

<Joshue108> new version 21- nov In content implemented using markup languages, the purpose of user interface components that serve a conventional purpose can be programmatically determined.

<Joshue108> new version from AWK In content implemented using markup languages, user interface components that serve a purpose identified in Appendix B can be programmatically determined.

In AWK, there was a link to purpose of controls.

<Joshue108> Mockup http://rawgit.com/w3c/wcag21/purpose_of_controls_changes/guidelines/index.html#purpose-of-controls

AWK: There was a survey with the different versions. there was a version we agreed on in principle.

Part of what we were talking about was seperating out the list. We should focus on the list today. This list can be a seperate doc or appendix. It is lengthy so I dont think we want it in the SC.

Core questions: Is the list normative or not? What should be on it? What is on it is easier if it is not normative.

AWK: The list of controls is in the survey and there is a version in the raw git.

First and foremost lets discuss the survey.

Current versions are not normative. Drafts for consideratoin

Joshue: Was the new AWK version closest or is the one from 11/21 closer?

AWK: The one that I put in that says new version from me, we have not talked about on the call.

It is a decent strawman if we like appendix approach but I think we should focus on normative/non normative

Lisa: Agrees

JF: We have a couple of issues here. The first is the core questions out there. Is this fixed list of controls normative or not? Then what's on the list? I think the list needs to be normative. For us to make progress towards the larger goal of transformable/personalized web content, we need a first step. That is the goal of this SC.

<Lisa> we realy need to focus guys.lets just focus on whether it is normative. we can probebly just see if anyone can not live with a normative list lik in apendix b

<Lisa> example of marked up content: https://a11y-resources.com/developer/coga-personalisation

The biggest issue is that personalization is still a very new. We don't have content so its marked up to support personalization so we don't have tools to support it. WCAG is the starting point.

It is a fixed, limited set of controls we see regularly, then we can proof of concept tools to show how to personalize the content. As a AA criteria, we may get light weight tools and start to build a corpus of tools on the internet. For that reason, I think we need a constrained list. What is on the list is the hardest issue.

The original list has 100 items. I reviewed and there isn't much to trim despite gut reaction. The items on the list are fixed and common. We also need to discuss what types of controls. Form inputs, links, and hten more common buttons.

<AWK> AWK: primary reason for this list to be normative - makes the SC testable and unambiguous and the potential list size is huge so needs to be limited to start. Primary reason for the list to not be normative is that we don't want to step on personalization standards. However, if we can keep the list small and in an agreed on state I believe that we will be ok.

Lisa: I think its important to focus on any issues on whether it should be normative. The order is important. Normative, list, then SC text

Last call there were people who couldn't live with it being normative. The people who were OK with it normative were ok with it being an appendix.

<JF> +1. count me as one of those people who believes the list MUST be normative (for testing and measurability reasons)

<gowerm> -1

<kirkwood> +1

Can we ask who is ok with Normative?

<Lisa> +1

<marcjohlic> -1 can not go with normative.. conflict issues with other standards

Joshue: I was going to suggest we get to that. Who is OK with it normative?

<Glenda> +1 normative

<AWK> +1, so long as the list is small

<Kathy> +1 normative

<Brooks> +1

Can someone speak to why it shouldn't be normative?

<Makoto> +1 normative

<marcjohlic> Strongly feel that ARIA / personalization or HTML5 should maintain a normative list such as this

<KimD> -1 as it's too much of being a tech spec, plus what Josh is saying.

<alastairc> +1, normative list of purposes, non-normative techniques (i.e. how you do it)

Joshue: If the list is not normative it gives us more room to rework the list. Also, is this like aria-labelledby for COGA.

+1 normative.

<Mike_Pluke> +1 normative

<alastairc> MarcJohlic - not sure what you mean about conflicts?

<laura> +1 normative

<steverep> +1 to normative

Joshue: Is that my thinking for this? Why don't we just use aria?

<AWK> @gowerm, that is why we need to make the list small and as future proof as we think possible

<marcjohlic> alastairc - I mean that I forsee conflicts down the road with ARIA, HTML5 (autocomplete for example). I just don't see why WCAG would be the standard to define names like this. I feel it's much better suited in ARIA / Personalization or HTML5

Lisa: There is a working draft in aria for implementation, purposes of conforming to this but that is only one solution. There are other solutions such as schema and autocomplete.

<gowerm> @awk, and how much inspection has this list had

<AWK> @gowerm, do we think that input purposes like name, address, email will go away?

<Lisa> https://a11y-resources.com/developer/coga-personalisation

<gowerm> Alastair, for the record, what happens if another spec required for a technology conflicts with this?

<JF> @gowerm - strawman... give an example please

Lisa: this isn't a specification. this says you have to find a way to identify it.

<alastairc> marcjohlic - ok, but those are far wider, if we refer out to whole specs then that is massively bigger. We need a normative list of purposes, and techniques for each. Some will be HTML5, some ARIA (maybe), some metadata (microdata).

Joshue: My concern is that you are asking developers who are just learning aria to learn something new.

<gowerm> We come up with our list based on html5, and then html5 changes its list of autocomplete items. Immediate conflict

Mike_Pluke: In my head its clear that this has to be normative because it scopes the SC. If appendix B is not normative, I can just ignore it.

Because it is referenced, it effectively scopes the SC by giving the field of applicability.

<Lisa> Alister, the apendix isnt a speck. so there can not be a confict. you can say it with any speck

<gowerm> That is how all sufficient techniques are written

JF: There seems to be some confusion. We are not specifying a technology. You can use any tech you want, including tech that isn't invented yet. All we have is common components on a page. It doesn't matter what you call them as long as they are associated with a specific purpose.

These are common purposes. We can't send this off to another spec. ARIA and HTML5 are techniques not the SC.

<alastairc> gowerm, by prescriptive attributes, yes, it is a list of the purposes, then the html/microdata etc are separte.

Lisa: We are not saying how to do. We are saying what to do.

It can't conflict.

<Lisa> exactly

<gowerm> SO there are no keywords?

Marcjohlic: That clears up a lot of concerns for me. So we are saying that if a field meets a purpose, we are only telling them they have to identify that purpose not how to do it.

<gowerm> There are no reserved words that identify the purpose.

JF: Yes, the reason implementation comes up is because we had to show how to do it as an exit criteria.

<gowerm> That was a question: there are no reserved words that identify the purpose?

These are examples of technologies but we need to focus on the first two columns: Terms and what they mean.

MarcJohlic: Is there a list I can view?

Lisa: I will send a link.

<Lisa> https://a11y-resources.com/developer/coga-personalisation is an example page

<Zakim> AWK, you wanted to say why I believe that this can't be non-normative

AWK: I think there is a lot of risk in it not being normative. The author/developer needs to know what they have to do to claim its done. There also needs to be a way to an author to respond to complaints that they haven't done enough.

<Lisa> example with autofil https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill

This being normative provides a safe harbor of sorts. Some people will only do what's required but others will do more. It does feel like a long list but also feels like a safe list. There are a few we could take out but if it only has name, address and email those feel safe.

No, I'm not suggesting only those three but if we look at the list to see what is good for the next 10 years, I think we can have a safe list that promotes the concept. If we don't have a normative list, we won't hvae this type of SC.

<Zakim> MichaelC, you wanted to say structurally an appendix is probably not expected to be normative, so instead of an appendix it would need to be a new top-level section (before the

<marcjohlic> What is it in that example that shows this Purpose of Controls? I'm seeing good ol standard HTML - not anything new that would, for example, identify that I"m asking for a "Job Title"

<JF> +1 - the list MUST benormative

MichaelC: Appendices are not usually normative so people may not expect that it is.. If we want it normative, we should make it a section.

<Lisa> this is not a list of terms

jasonjgw: My concern with a proscribed list is that a technology developing this may have to subdivide the list conceptually.

<Lisa> that is what we have

We need to allow flexibility instead of a defined list. Also, we have very limited experience with the consumer side of this material.

To the extent that these technologies evolve and we discover what is more/less useful, we may have a different list.

<Zakim> gowerm, you wanted to say, so are all the prescriptive attributes given in the glossary now being withdrawn now? and to say do you really think we can, in the time allotted create

I'm concerned that this is an AA without sufficient experience with its benefits.

<KimD> +1 to Jason

<Lisa> yup

<alastairc> gowerm - true, that was a previous attempt at compromise, we've dropped that in favour of HTML5 & microdata as prefered techniques.

<alex> thanks Andrew

gowerm: I think I just heard withdrawing a statement of the requirement that a field be indicated through a standard, explicit term. Is that correct because that seems different than what was originally propose.d

If that is true and there is not assigning of how the list needs to be specified, how does this help?

<JF> Mane = 名 = ชื่อ = Nombre - all will be tagged with a metadata semantic that describes "name"

Finally, the list has a lot of duplication, lots of similarities. I don't see how we can normalize the list in a meaningful way within this group in the timeframe.

Can we futureproof this for 10 years into the future? Those are hte 3 things I'd like ot address.

<Zakim> JF, you wanted to respond to Mike G's question

JF: We are dealing with a concept. The concept of home. You might have an icon of a house. For people who don't understand that, we want to tag that up with metadata that disambiguated that icon. I agree that

there are items that are synonomous. What we need to be doing is go through the list and determine if the list will stand the test of time. If job title is too ambiguous, lets strike it. At the end of the day, we need a measurable list ot test against.

To Jason's point, we don't have AT because we don't have content. We don't have content because we don't have AT. We need to break that cycle by starting with adding metadata to the web.

<Lisa> none of this is for simplifiacation

<Lisa> no

Joshue: I think we have a useful list, I'm hearing the list needs to be normative for this to work, I'm hearing we need to widdle down the list to what we can live with.

<Lisa> simplifaction aspects got cut out a long time ago

<gowerm> So, Lisa, simplification is not a consideration or goal at all?

MarcJohlic: If we make this normative and something changes and there is no way to specify it, how do we make that work?

JF: I hear that concern. The reason for the spreadsheet is to see if the concept can be achieved today to limit that risk. I was mapping out the SC by techniques. Can we achieve this? I think today everything can be achieved using exisitng tech.

I don't the techniques will go away because of the importance of backward compatability.

<gowerm> The ability to simplify/clarify through symbols, etc., is not in consideration?

The one concern I have about not having a specific list, this begins to look like 1.3.1 which we left open deliberately but has a lot of ambiguity in testing.

<Lisa> maybe we can see if anyone still can not live with it normative

<KimD> +1 to Alex

<Zakim> AWK, you wanted to speak to the list, COGA/HTML5/Schema.org

Alex: I agree it should be normative. This a chicken/egg thing. We need to recognize that sometimes we get an egg and a chicken doesn't come. This could potentially fail in the market place. I'd prefer this be voluntary instead of a legal requirement.

<Lisa> alex now we are talking about the list being normative

<JF> See the Google Docs sheet here: https://drive.google.com/file/d/0B8dsTwtY5GvmMGplTUY4UmZzX3M/view?ths=true

AWK: We originally saw a very long list. It is possible for the personalization taskforce to come up with a much more comprehensive list than what we have. This list, particularly the inputs, came from COGA, schema.org, the HTML spec. I think we are looking at what is the in common list.

<marcjohlic> Sorry to show my ignorance on this, but can someone give a 15 second example of how this would be tested? How do we show that the dev has described the purpose of the field is for cc number for example? Just manual checking or based on looking for autofill attribute or?

This makes the list shorter. If we are only looking at the in common list for inputs, then we are looking at pretty safe fields that are not going away.

<Lisa> that came from autocomlete

<JF> at that google spreadsheet, look at "Sheet 1"

To Alex and Mike G's point, does this actually do anything? That gets to implementation. If we don't have a way of doing anything with the properties, then we won't have the SC at that point.

<Joshue108> +1 to building on HTML5 autocomplete

Lisa: A lot of duplication has been addressed in the list. The other question is, Is this complete. The answer is no. But while this isn't complete, it is a common list. I'm hoping a lot of the duplicates can be addressed during hte discussion of the terms.

<Glenda> imagine a new attribute called coga-purpose

Do we have concensus that this should be normative?

<Glenda> <label>Your First Name<input type=“text” id=“fname” coga-purpose=“given-name”></label>

<Lisa> contextual dependece has been claified in the crrent version

<Lisa> it has been adressed jason

Joshue: We will do a call about normative after we finish the queue

<KimD> +1 to Jason

Jason: I think there are serious concerns about how this implementation will work. This will make 2.1 an experiment. I would prefer this be carried out in research projects and not included in WCAG.

<gowerm> To confirm, this would meet the SC? <label>Your Name><input type="text" id="yourname" mypurpose="aKeywordUsedByMyTechnology"></label>

<Lisa> the discussion is normative

<JF> BRoadly speaking Mike, yes

After research, I'd like to see this addressed in WCAG. That is my underlying perspective. If we are going to put this in 2.1 then I think we need flexibility. I'd rather this not be AA without more experience and assurance of its use.

<AWK> @gower, if you can show accessibility support for it, sure.

<Lisa> note: we only get though CR if every term has AT support

<marcjohlic> @Glenda - that would be great, but it makes me nervous making this normative when a coga-purpose doesn't exist yet. I get that someone needs to get the ball rolling, but can the ball start rolling w/ just a non-normative appendix or does it have to be normative?

<Zakim> JF, you wanted to speak of implementation. To start, the best we can hope to see is a browser extension, but once there is enough content, then software companies have a valid

Joshue: What comes to mind is How will this happen?

<AWK> @marc <label>Your First Name<input type=“text” id=“fname” autocomplete=“given-name”></label> would also work

<Lisa> actualy texthelp is working on an implemention

JF: To address the questions, we aren't going to have any complex AT to support any of this because there is nothing to support.

<gowerm> AWK, and how would you meet this with PDF?

<AWK> @gowerm PDF is not today implemented using markup languages

I acknowledge this is still immature and young tech. My concern is that if we make it into a research project, 10 years from now we are still parsing the research and haven't helped anyone.

<marcjohlic> @AWK - That I get.. but that's why I'm thinking we build this initial list using only widely used attributes that exist in HTML5 and ARIA.

<Lisa> NOTE text help and other have commited to support it

<Glenda> imagine a new attribute called coga-purpose

<Glenda> <label>Your First Name<input type=“text” id=“fname” coga-purpose=“given-name”></label>

<jallan> scribe: jallan

<Lisa> so over the next year we will have serious AT support not just browser extention

gs: this is a new piece of metadata. spent more time debating it than it takes to implement.

<JF> @Glenda, more like this: <a href="http://example.com/contactus/" itemscope="" itemtype="http://schema.org/ContactPage">contact us!</a>

gs: should help coga. this is very basic

<Rachael> Glenda: There was confusion earlier in the call. This is just a new piece of metadata. It doesn't change the on screen labeling, it is just a consistent piece of metadata. We need to help COGA. This is basic and going to help. I am against putting this back to research.

josh: wrap up
... should this be norm or non-norm
... where should list live?
... what goes on the list?

<Lisa> +1

<Glenda> +1 normative

<gowerm> Provided we are not perscribing the attributes, I can live with this.

<kirkwood> +1

<alex> +1

<JF> +1 for normative

<Rachael> +1 normative

<AWK> +1

<Brooks> +1 normative

<Kathy> +1

<laura> +1

<Makoto> +1 normative

<Joshue108> +1 to normative

<marcjohlic> +1 for normative (nervously until we tackle the list) :)

josh: +1 for norm, -1 for non-norm

<JF> @marcjolic - fair enough - let's tackle the list

josh: the list, how much work can we put in, given short time.
... seems folks want list normative

<Lisa> +1 i can live with it

josh: section or other page

<JF> @Za,kim, tough, I need to speak :)

awk: chairs and michael to figure where list should be

<Lisa> +1 to not worring

<Glenda> agreed - versioned normative

awk: not worried about location

<Mike_Pluke> +1 not worried about the location

josh: MJ can you live with discussion?

<Mike_Pluke> +1 normative

mj: ok with normative. very common things, autofill, html5 attrib, aria attributes. ok

mg: my comments in irc. can live with it

<JF> re: schema.org metadata values - yes, widely consumed by *ALL* search engines today

josh: will review SC language a little later

<JF> "Over 10 million sites use Schema.org to markup their web pages and email messages." - source: http://schema.org/

awk: what are we closing on. normative or specific list.

<marcjohlic> The only reason I called out schema.org is because in my dealings with FEDs I've never had one come to me asking about schema.org.. Always questions about HTML5 attributes, ARIA attributes, etc - So I'm more comfortable building our list based on that. (like I say though, it may be my ignorance about schema.org)

josh: group agreed to normative, still working on list

<Glenda> We need to finalize this now.

josh: use list from Nov 21 call

<Glenda> We’ve got to get this in for COGA or we didn’t do what we NEED to do for WCAG 2.1.

awk: have SC text that works, agree to normative. now, need to look at proposed lists

<JF> @marc - again, don't confuse technology versus 'outcomes' - if you can meet the requirement using *A* technollogy that is accessibility supported, then yuo are good to go

<JF> My research shows that *I* could meet the list using schema.org metadata values and Microdata annotation

awk: seems strong support for most, scattered concerns. survey various lists

<marcjohlic> @JF Yep, OK. (Thx)

RESOLUTION: WG agrees that list should be NORMATIVE!

<AWK> https://www.w3.org/2002/09/wbs/35422/resolving_purpose_of_controls/results#xq6

awk: link and button types

https://www.w3.org/2002/09/wbs/35422/resolving_purpose_of_controls/results#xq6

awk: many on list have 11 (no objections) and should be in, anything with no 'no' votes should be in.
... objections?

<Lisa> +1

<JF> +1 - no "No's" are in

ls: things with 2 no, send=submit, synonyms. should not remove.

awk: is send under email or editing actions.

ls: it is under editing actions. it should be submit not send

<Joshue108> Can I suggest we get agreement on the ones that are not controversial first?

ls: if you use submit in html then you conform.

awk: need to agree on non controversial first.

<Zakim> steverep, you wanted to ask why we need to distinguish between buttons, links, and inputs, and also ask if this is a least common denominator list?

<Lisa> it is just to make it easy to find

sr: these things overlap. may have a similar icon. should not need to delineate between them
... many ways to implement these.

<Lisa> we dont deliminate it thoug

<Lisa> we just have headings to make it easy to find

josh: reduce duplication, is that what you are getting at?

<Lisa> this is a non isue

<Lisa> please let john or me explian

<JF> @Steve - total agreement - thus moving towards "User Interface Controls"

sr: yes. may have a link or modal dialog. many ways to reach goal.

<JF> yes

<Lisa> yes

<Lisa> or autocomplet

sr: not sure about all. not my area. have these been mapped to schema.org schema

<JF> JOsh, can i respond to those questions please?

sr: focus on least common denominator.

<Lisa> every item went to review

<Zakim> JF, you wanted to answer Steve's question: "User Interface Controls"

gm: first time list reviewed. all 11 pass, is ok. should be reviewed again. this is a first draft

<Glenda> We are not writing this in stone yet. This list has been reviewed very deeply by experts.

<Joshue108> -q

jf: SR questions, yes thought of these already. link vs button... it is a control that does something. SC defines the something.
... see spreadsheet. map purposes to metadata schemas, etc.
... all can be mapped to schema.org. some are fuzzy. but extensible. work to be done.
... JF has contacts at search engines.

<steverep> @JF, can you point me to that spreadsheet?

jf: have at least 1 technique for schema.org

<gowerm> So are we saying that all developers are going to have to use schema.org where html5 does not provide an attribute?

josh: ? is there a generic list?

<JF> no mike, I am saying that one existing technique today is to use Schema.org, but please feel free to explore other technologies

ls: these are just heading 'user interface controls'

<JF> outcomes is what counts, not technollogy

<JF> @Steve - https://drive.google.com/file/d/0B8dsTwtY5GvmMGplTUY4UmZzX3M/view?ths=true

ls: have headings to make items easier to find. need to remove duplicates.
... MG, we did not add new terms. tho lots of requests
... but no time for new and review

<gowerm> Didn't add new terms since when?

ls: want to keep it simple
... no new terms, all are in glossary appendix

<JF> @steve, the "Headings" are there for us to conceptually understand where the controls are most commonly used

<Glenda> the headings are for US to understnad this!

<gowerm> Right it needs to be reorged. Absolutely.

jason: need to be reorganized... headings will be seen as normative and confuse folks

ls: can take out heading.

<Glenda> for simplicity, we take out headings

jf: agree. list was very long. headings for chunks for presenting information. don't need them

<gowerm> Remember, every term we put on this, we are going to be requiring a developer to provide markup for it, markup that doesn't exist in html5 for links or buttons

sr: organize semantically

<JF> @Mike - not true, sorry

<Zakim> steverep, you wanted to say those headings will be interpreted as normative though, so reorganizing semantically is necessary

<Zakim> AWK, you wanted to propose accepting all for the next WD except for "move", received, date, higher, lower. And "send" is referred to as "submit"

<JF> it's metadata - and that can be applied today to any page element

awk: reviewing 1st list, this is first draft and need implementation
... propose accept all, except strong objections - move, receive, date, higher/lower,

<gowerm> AWK, so you don't want to even hear from the person who didn't support it and why?

awk: send should be renamed to submit.

<Lisa> higher/lower

<Lisa> needs discusion

mg: ask for response to survey. but ignoring feedback. hear out the objectors.

awk: sure, trying to propose a frame work.

<Lisa> _i need to explain why higher/lower is imporant

<Lisa> I can live with cutting move, receive, date

josh: survey, lay of the land.

<Glenda> and if we can’t live with x, y and/or z items…we can easily kill them in the next round

<gowerm> If the items that have had no dissenting votes are put in a group, that's fine, but if anyone has entered a concern, it should be discussed.

josh: all 11 votes are a base line, then look at others
... 25 items have 11 votes

<gowerm> And we should review the general comments too

josh: those 25 are accepted as core... is that ok
... only all yes, then work through the others
... any objections to items with all YES being core?

<gowerm> I would also like to review my top general comments

brook: object. not a reasoned purposeful, not looking at what benefits users.

jf and josh don't understand objections

<Lisa> this list originated from coga

<Lisa> so it benifits user

josh: list based on lots of inputs.

brooks: not sure how autocomplete maps to user need

jf: it is a start. these are implemented.

<gowerm> But does autofill actually relate to purpose?

<gowerm> Always?

josh: broad support. not arbritrary

<JF> NOTE: itr is *autofill*, and not autocomplete (which is a different but similar concept - type ahead/predictive software)

brooks: this is transformative. very much needed. don't feel right. survey is still open. if no objections, I will support

ls: list has been around for 2 years. see gap analysis - identifying user needs. some added from autofill per jasonW. reviewed by COGA and EPUB.

<Zakim> gowerm, you wanted to disscuss existence of the list and how it has changed.

gm: list is not same as list presented in issues. thought aria rejected this list.

ls: list is a working draft for module to aria
... was a decision by aria 2 years ago, with its own task force

<Lisa> https://rawgit.com/w3c/personalization-semantics

mg: many terms in original list have no bearing on this list.

<JF> Q: why are we discussing techniques here?

<marcjohlic> @Lisa I'm getting a 404 on that link.. Anyone else?

ls: some terms were removed, to reduce scope. everything in this list are in personalization semantics.

<JF> @Marc, check to see if the URL has an " at the end - if yes, remove it

<Joshue108> We need to get some agreement on what are the core items for this list.

gm: list has changed in 2 years.

<marcjohlic> @JF nope, not quote or other special character showing in my browser.. did it come up for you?

<marcjohlic> I'm getting a 404 on this link https://rawgit.com/w3c/personalization-semantics

jf: can we focus on the list. if not enough time to review. then take more time.

josh: appreciate brook and gowerm comments.

<Lisa> missing/

<Lisa> https://github.com/w3c/personalization-semantics/

josh: are the 25 yes items a provisional core

<Glenda> Can we mark each item that doesn’t have all 11 “yes”es as PROVISIONAL?

josh: any objections?

<marcjohlic> https://w3c.github.io/personalization-semantics/

<Lisa> https://rawgit.com/w3c/personalization-semantics/master/semantics.html

<Lisa> +1

<AWK> +1

<Joshue108> +1

<JF> +1 to all of the All Yes responses

josh: any objection to all yes items in survey?

<alex> 0

<kirkwood> +1

<marcjohlic> +1 to all Yes

<Kathy> 0

<Glenda> +1 to all of the YES responses

<Makoto> +1

<gowerm> 0

<Brooks> 0

<laura> +1

<Greg> +1 even though it's not a perfect list

<Glenda> Can we mark each item that doesn’t have all 11 “yes”es as PROVISIONAL?

awk: review prefer nots

<gowerm> I would also like to review my comments

josh: have good SC language.

awk: review no no's

EXPAND

<Greg> I would say the weakness of Expand is that controls toggle between Expand and Collapse.

awk: expand - triangle to expand

<Glenda> Expand, Higher, Lower, Post

mg: why not expand/collapse
... if control toggles expand and collapse. why not include both terms.

<Glenda> @alastairc you were “prefer not” on expand

ls: conflated with 'more'

mg: need to be careful about synonyms and homynyms

<AWK> @steve I think that we will need to reuse the sentences from autofill or schema.org

mg: if you have confusing terms, need parenthetical clarifications

ls: a list was sent with defintions

<Greg> Listing names only is extremely problematic.

awk: does schema have expand/collapse and more/less

<Joshue108> +1 to Mike

<Glenda> HIgher and Lower | Prefer No = AWK, David MacDonald, Laura Carlson

<alex> For expediency, let's drop this one. Mike has casted enough doubt.

<Greg> State should be adjectives "Expanded" or "Expandable", rather than the verb "Expand".

<AWK> +1 alex

<Glenda> +1 alex

<Glenda> let it go…move on

mg: worry about authors being confused. heading with control that expands/collapse - two differerent actions. but the purspose of heading is different

<laura> Need to drop off the call in a few minutes. I can live with including all of the terms in the survey that I responded “Yes, but prefer not”.

awk: higher/lower?

ls: very important IoT, raise lower temperature, volume, etc.
... need to keep

<Zakim> steverep, you wanted to ask if we plan to describe each of these in a normative sentence (similar to schema.org)?

sr: all terms need definitions.

awk: that is the plan, already have defintions for these

mp: list need defintions. some terms are vague. a bit unconformatable with some

<Lisa> · received -open the received folder · sent -open the sent folder

<Lisa> we had the defintions. I do not know why they were taken out.

josh: thought I understood terms untill we started talking about them.

do we have a link to list with defs?

<Zakim> gowerm, you wanted to say higher/lower are ambiguos. This has to be dysambiguated

mg: see my comments in survey. need for disambiguation. nuance terms... view from authors perspective. many concerns

<Lisa> they were taken out of the last list. not sure what is happning\

<JF> https://drive.google.com/file/d/0B8dsTwtY5GvmMGplTUY4UmZzX3M/view?ths=true

<Lisa> i resent the email

jf: hear concern, see spreadsheet. intended function, intended definition. please review

=== 15 MINUTE BREAK ===

<AWK> We will resume the call at 12:15 Boston time

<Lisa> yup just taking a few muinit brake

<AWK> Call resumes in 6 minutes

<AWK> https://www.w3.org/2017/08/telecon-info_ag-extra

<AWK> Call resumes in 5 minutes

<AWK> Call resumes in 2 minutes

<AWK> Call resumes in 1 minute

<AWK> Restarting now

<AWK> Scribe needed

<alex> awk: David misunderstood the ToC one. He agrees to Yes

<alex> awk: Mike thinks Expand is unclear

<alex> awk: ok with higher/lower

<Lisa> I am fine with that

<Lisa> increase and decrease

<Glenda> I suggest we not wordsmith now

<Glenda> definitions will suffice

<alex> john: increase/derease is probably clearer

<Lisa> +1 glenda

<Glenda> +1 to adding higher/lower in to the list

<alex> david: i'm flexible about higher/lower

<KimD> * have to leave early for other meetings

<alex> awk: let's talk about post. david and alastair are "yes, but prefer not"

<JF> +1 to difference (Public vs Submitting)

<alex> lisa: "Post" is public which may not be the case for "send"

<alex> john: Post is different in terms of exposure

<JF> @David, no more or no less than what we actually need

<alex> david: are we trying to aim for a specfic number of items here?

<alex> awk: no, we are not

<AWK> Alex: The problem is that the difference between the number of recipients (send to 2 people? send to make public?)

<JF> Post = Public, Submit/Send = Private

<AWK> ... what if send to twitter followers to a locked account?

<AWK> JF: My interpretation is that would be a post

<AWK> Alex: who gets to see it depends on how the user structures the settings?

<AWK> JF: the difference gets a little blurry - twitter DM="send" tweet="post"

<AWK> Alex: emails can get forwarded - thought was 1:1 when sent but not always stays that way

<Lisa> post - submit and posts the form data. Item will be visible to other parties.

<alex> lisa: we need send

<alex> awk: post is covered by send and submit, but more specific

<alex> daivd: sumbit is neutral. okay with it

<JF> Q

<alex> awk: any objection to use submit

<Rachael> +1 to combining them into a single submit

<Glenda> +1 keep submit (and drop “post” and “send” for now)

<kirkwood> +1 to submit

<Lisa> +1

<alex> david: post or send can both use submit

<alex> awk: no "post"

<alex> awk: lisa is ok to remove "move"

<Lisa> received -open the received folder · sent -open the sent folder

<Rachael> 202-231-4105

<Lisa> :)

<Lisa> do that all the time

<alex> awk: let's look at forward, received, and sent in email

<Rachael> s/ 202-231-4015 /

<alex> awk: david has comment on forward, but what does "Next" mean?

<alex> john: "next" is not in the spreadsheet

<alex> awk: it is

<Greg> Navigating through a list of messages of anything else usually involved Next and Previous (and First and Last, which are strangely omitted).

<alex> john: it is a typo

<alex> awk: add "forward" without "next"

<Greg> Forward and Back are often synonyms for Next and Previous in navigation UI.

<alex> marc: are we saying open is okay to open email?

<Greg> I see Received and Sent as more specific and less common than I'd prefer, but they're not objectionable.

<alex> awk: no objection on "received" and "sent"

<alex> awk: let take up "comment"

<alex> awk: mike commented, but not here

<lisa> comment -submit a comment on the current item

<lisa> date opens a date picker

<alex> awk: let's move to "date"

<alex> laura and david are yes, but prefer not; mike is no

<alex> awk: comment is about making a comment, not submitting a comment

<alex> awk: why "buy", not check-out?

<marcjohlic> The only extra I can see for "buy" would be a "buy now" button that does the checkout all in one

<lisa> add to " add" Often involves adding the current item into a shopping cart.

<Greg> These terms are extremely ambiguous: could we use phrases instead of names to reduce the problem? For example, "Add to cart", "View cart", and "Complete purchase".

<alex> awk: we can't address "buy"

<alex> awk: let's talk about "compose"; mike has comment

<alex> lisa: if new is in, we don't need "compose"

<alex> awk: don't see "new"

<JF> We have "Compose"

<Glenda> +1 to putting it in

<JF> +1 to putting in

<alex> awk: "compose" is in

<alex> awk: let's go to contact us, about us, our phone, our email

<JF> <p>To make a booking, call <a href="tel:+13174562564">317-456-2564</a>

<Glenda> Because it helps you FIND it

<alex> awk: mike is not sure people use link to phone

<Glenda> the AT for COGA could help surface it easily

<alex> john: people do so today. example shown

<alex> awk: how about drop phone and email

<JF> +1 we see this in the wild already

<alex> lisa: let's not

<Zakim> Greg, you wanted to ask for clarification whether there is a distinction between Date on date picker controls vs. on text entry fields asking for dates.

<Greg> Asking for clarification whether there is a distinction between Date on date picker controls vs. on text entry fields asking for dates.

<alex> marc: aren't they redundant

<marcjohlic> Just trying to see if we can whittle this down. I would imagine a Contact Us link would have such wording in it.. if not, then why wouldn't I want to put some sort of contact attribute on the phone number?

<alex> greg: is adding friend the same as adding shopping item in shopping cart

<marcjohlic> To indicate that this phone number on the page is specifically for contacting the company (vs support or who knows what else)

<lisa> add -add the selected item from it’s current context. If no item is selected add the item identified with the control.

<alex> awk: they are different context

<lisa> add -add the selected item from it’s current context. If no item is selected add the item identified with the control.

<alex> greg: we can potentially have same term used differently

<lisa> we can have the catagories in the understading

<alex> awk: should we remove context/categories?

<JF> focus on the concepts

<Greg> These terms are extremely ambiguous: could we use phrases instead of names to reduce the problem? For example, "Add to cart", "View cart", and "Complete purchase", and for “Go to contact page” and “Email us”.

<lisa> to late for that type of change

<alex> greg: there is difference between date entry and date picker

<AWK> We have 1 hour left

<AWK> Ideally not just for this item

<JF> <p [metadata value="contacting us"]>To make a booking, call <a href="tel:+13174562564" [metadata value="our form"]>317-456-2564</a></p>

<marcjohlic> phone

<marcjohlic> yep

<alex> john: contact by phone and email is common

<alex> this is not only for skype, btw

<JF> 3 points: "Categories" were established for chunking purposes so that we could start to think of the terms in some form of context

<lisa> terms -terms and conditions about the current Web page or application

<JF> Point 2: the "terms" are an attempt to conceptualize the intent: for example, i18n will change the "terms" that the author would reference, but what is key is the metadata values

<alex> awk: should we remove category?

<alex> awk: no objection

<JF> Point 3: see my example code previously, showing in pseudo-code terms the intent

<alex> awk: should we look at the last 10 with one objections?

<alex> john: how about put those as "at risk"

<alex> awk: how about include them to cfc

<Greg> FYI I'm not sure why distinctions are being made between Family Name and Given Name, and between a various links, but not between Main Phone Number, Support Phone Number, TTY Phone Number, etc. It’s a weakness, but not a blocking point; I assume we inherited the omissions from one or more of the markup systems.

<alex> john: i can live with it

<alex> lisa: agree

<alex> awk: does Marc think Mike's comment is resolved?

<alex> marc: yes

<Zakim> steverep, you wanted to request the CFC include a link to what we actually plan to publish

<alex> steve: hard to follow, please have normative description

<alex> jason: terms need to be defined

<alex> awk: no objection to "contact us", "about us", "our phone", "our email", "chat help", "services", "products", "terms", "social", and "my profile"

<Glenda> suggest putting those 2 in (that lisa requested) as “at risk"

<JF> I WANT TO STRONGLY CAUTION NOT TO CONFUSE AUTOCOMPLETE AND AUTOFILL - they are separate and distinctly different features/functions

<Glenda> AWK - is about FINDING something…

<alex> glenda: let's put subject and comment as "at risk"

<alex> john: keep autocomplete differentiated from autofill

<lisa> +1

<JF> +1 to dumping the fax values, +1 to listing others "at risk"

<alex> awk: should we put subject and comments as "at risk"?

<alex> subject and comment are at risk

<alex> awk: propose to remove all not in autofill

<alex> marc: I don't initially recognize additional name and additional name initial

<alex> marc: i can live with additional name

<alex> awk: no autofill for additional name initial

<JF> Alfred E. Newman - "E. is both middle initial and for autofil, middle name

<alex> lisa: but do people know what initial means

<alex> lisa: this will explain to people what initial is

<Zakim> Greg, you wanted to say I'm a little concerned about making Additional Name a requirement

<Greg> I'm a little concerned about requiring use of things that are vaguely defined, which I'm assuming is the case with Additional Name (but haven't had time to check). There's a big difference between Schema.org saying this would be useful for authors to mark up additional fields, vs. us *requiring* that authors do it. If one country's form ..

<alex> john: cited Alfred E Newman as example

<JF> per HTML5 Autofill token values: "Additional names (in some Western cultures, also known as middle names, forenames other than the first name)"

<lisa> additional name -additional or middle name (of the user)

<alex> greg: question if additional name is useful?

<alex> awk: developers would have to map middle name to additional name

<Greg> If one system allows marking a field as Middle Name, but another system does not have that, to comply with AG would they have to mark it as Additional Name because it doesn't fit into our more specific categories?

<JF> Generally, authors are encouraged to use the broader fields rather than the narrower fields, as the narrower fields tend to expose Western biases. For example, while it is common in some Western cultures to have a given name and a family name, in that order (and thus often referred to as a first name and a surname), many cultures put the family name first and the given name second, and many others simply have one name (a mononym). Having a single field is therefore

<alex> john: fine to not mandate additional name

<JF> https://www.w3.org/TR/html51/sec-forms.html#autofill-field

<alex> john: fine to remove all the types of names

<lisa> add name back in

<alex> lisa: but we don't have name on the survey

<lisa> _1

<lisa> -1

<marcjohlic> +1 to JF's proposal to just keep "name"

<Rachael> +1 to name as a starting point

<lisa> john lets just go though the list

<alex> jason: we need to give people flexibility to implement

<Greg> Keep in mind that dropping tags potentially does hurt users in countries where those are common (e.g. Middle Initial); we'd not be saying they have to provide a middle name field, but if they did provide one they'd have to identify it. I fear having fields with a bunch of fields all marked up as "Name" or "Additional Name", which is not as helpful as more specific fields.

<lisa> we need to add name

<alex> jason: some may use name and some may use first and last name

<JF> @Lisa, we can give encouraging instructions in the Understanding and Techniques documents that explains and shows the benefits of a more granular approach

<AWK> @greg - developers can still use additional fields, just doesn't mandate them

<Glenda> put name back in

<alex_> awk: remove additional name and initial; lisa object

<JF> I agree

<alex_> mike: line 2 and 3 of address should be addressed as a label

<alex_> mike: they are all address

<alex_> jason: many address field is context sensitive; developers should have flexibility

<lisa> +1

<Greg> ...important.

<alex_> marc: having these specific items mislead people

<Zakim> JF, you wanted to say there is nothing here that forbids a more granular ontology: it's about the concepts, not the technology

<alex_> lisa: fine with just using address

<Zakim> Greg, you wanted to say I disagree with mgower: identifying address line 1, line 2, etc. is incredibly important for allowing auto-fill, which is important for anyone who has

<alex_> john: fine with consolidating

<Greg> I disagree with mgower: identifying address line 1, line 2, etc. is incredibly important for allowing auto-fill, which is important for anyone who has difficulty entering data or determining which data to input where. These are very common tasks, so making them easier if extremely useful. Yes, they don't apply in all forms or all countries or sites, but where they apply they are important.

<alex_> greg: breaking them up is important

<lisa> i agree with greag

<alex_> greg: want to make sure that it is okay to use address line 1, 2, 3 if developers want

<jasonjgw> This is my issue exactly.

<alex_> greg: using more specific fields should not be a fail

<lisa> que

<alex_> awk: similar with birthdate

<Zakim> gowerm, you wanted to say that this does not prevent someone from using autofill

<steverep> All of this is going to depend on the acessibility support

<JF> +1 to Mike's concerns - but we'll have Techniques for success (and Failure) that can provide that type of granular instruction.

<Greg> As I said earlier about the Middle Initial example, we don't want to force authors to use a generic tag like "Additional Name" instead of a specific one like "Middle Name", or use "Full Address" instead of "Address Line 1", if our enumeration only lists the more general ones.

<alex_> lisa: street address is part of address

<Zakim> JF, you wanted to say that there is a lot of "education" needed here

<gowerm> Greg, the only purpose that should be captured is entering name.

<alex_> john: this is about education in understanding doc

<lisa> we have to rap up jason

<alex_> jason: need to be clear that developers can implement

<alex_> lisa: i think we are clearing street address, and address line 1, 2, and 3

<JF> +1 to address (only)

<alex_> awk: agree, only has address

<kirkwood> +1 to address

<lisa> +1 t keep them

<alex_> awk: what do people think about birthdate, country code, country name, and postal code

<JF> +1 to Mike. Stick to the high-level abstract concept

<Glenda> and since month and day are in different order on different sites..this could help COGA and ANYONE!

<Glenda> I’m lucky…my bday is 12/12…so id does not matter which field is month and which field is day.

<gowerm> I'm not limiting. I'm just not insisting on it.

<alex_> lisa: the split of day, month, year is useful

<Glenda> The split will help people fill out the form accurately

<Zakim> gowerm, you wanted to say that the input part of this is much easier than it is for links or buttons. html5 inputs have type and name to use for this. It gets uglier in buttons and

<alex_> john: agree with mike to keep the high level abstract

<lisa> can you live what we have

<gowerm> I did lose my place in queue, AWK

<alex_> awk: we don't need to spell out to details

<AWK> sorry mike

<lisa> sorry i though it was from before

<JF> exactly!

<alex_> mike: links and buttons are more difficult

<JF> Microdata, RDFa, microformats (not recommended) - lots of ways of attaching metadata to elements

<alex_> mike: the more specific the harder for people to implement

<gowerm> Right, we are setting a baseline requirement that you have to indicate purpose in some way for these concepts.

<JF> +1, and then in Techniques we can "explode" the consolidation as Best Practices

<marcjohlic> +1 to consolidation

<alex_> awk: we can consolidate name, address, credit card expiration date, telephone number, fax number, and birthdate

<alex_> lisa: prefer not

<marcjohlic> Maybe look at it this way - are folks going to just put a random cc exp date on a page w/o requesting the other CC fields? Therefore covering it by saying properly describe CC fields

<marcjohlic> same with address, phone, etc

<marcjohlic> +1 to what John is saying now

<alex_> john: got to balance just tell people to use high level

<alex_> awk: we are overtime

<JF> +1, and I'll bring the stop-watch

<JF> ;)

<alex_> awk: will do a pull request and spend no more than 5 minutes tomorrow

<alex_> awk: we spent too much time on this sc

<alex_> lisa: i'm coming around to consoidate

RESOLUTION: to spend 5 minutes tomorrow to finish this SC

<gowerm> I'll review the notes, but hope you addressed harder issues ith links and buttons

<JF> bye Makoto

<lisa> Please click this URL to start your Zoom meeting: Lisa Seeman's Personal Meeting Room, https://zoom.us/j/7674613515

<AWK> trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

29 Nov 2017

Attendees

Contents

Purpose of Controls https://www.w3.org/2002/09/wbs/35422/resolving_purpose_of_controls/results

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output