See also: IRC log
<MichaelC> s/In content implemented using markup languages, the conventional name of conventional user interface components can be programmatically determined. (AA)//
<scribe> scribe:alastairc
<MichaelC> Silver meetup
MiichaelC: When at TPAC in Nov, there will be a bay area meetup on the Silver work. Expect people would like to participate, details closer to the date, it is on Thursday evening.
MichaelC: Any other announcements? Nope.
<david-macdonald> In content implemented using markup languages, the conventional name of conventional user interface components can be programmatically determined. (AA)
MichaelC: 8 comments, 4 supporting. A few against, comments?
Jason: The viability depends on
the definitions, there's a lot of work there. The acceptability
/ effectiveness will depend on detailed work that hasn't been
done. A good horizontal review would be desirable soon, get it
into the draft would be a good way to do that. Still has issues
that won't be resolved for a few weeks.
... For example, 'conventional ui components', then compare to
the HTML5 spec equivalent (auto-completion), there's a more
rigorous approach. That's a good example to use.
<lisa> new titile is Purpose of controls:
MichaelC: Bruce suggested a title change, Marc has issues with the words listed as definitions and whether they are examples or not?
Lisa: The title was meant to be "Purpose of controls".
<david-macdonald> hit refresh for latest version of answers
Lisa: It will help to achieve
personalisation, support the title change.
... We do need to harmonise, we know about the HTML5 and ePub
examples.
MichaelC: Bruce isn't here, but there is a proposed title change.
<lisa> +1
MichaelC: Does anyone object to
putting it into the draft?
... i think Marc Johlic's comment was similar to Jason's, but
do people present object to putting it out for review?
gowerm: I don't think we should put this out for review, it seems like we're just putting it out.
<Alex_> is the audio dead or just me?
<david-macdonald> my audio is fine
Lisa: We had a call to try and address everyones concerns. The thing under scrutiny is the definitions now. We had some quite different opinions on the call, and everyone was happy with the core SC text. The definition is there form the last couple of years, it isn't new.
<Detlev> is it going to be purpose of controls of personalisation?
<Detlev> Or
<Pietro> * audio on WebEx by browser is good
David: Echo Lisa, there was quite a bit of scrutiny, understanding the definitions need work.
<MichaelC> ac: definitions were to address JF objections
<MichaelC> list things in use today
<MichaelC> the subgroup liked, just needs cleanup
<Zakim> MichaelC, you wanted to ask how much time to clean up defs and to say defs are new from SC perspective
<Detlev> "Purpose of controls" won't reflect the personalisation issue if this is core
<lisa> from 2 weeks ago
MichaelC: Whilst the terms in the definitions have been used elsewhere, they are new to the SC. How long will it take to clean them up? If it's a week lets come back to it then?
<Alex_> p
Kathy: how does this support personalisation? We have a list of these in English, will that be for all of the languages?
Jason: To answer Michael's
question, not sure how long it would take, but I think it would
take a while, several weeks of work probably? Needs to be
specified closely. Also, on the public review side, the reason
here is we need more (external) review to progress.
... we can include notes to indicate the issues. This is on the
side of external expertise.
gowerm: I really believe that this is a new version, it should have the same scrutiny as everything else. To early for a CFC.
<MichaelC> ac: would like to put out with ednotes
<Alex_> Michael, you dropped me off the queue
<MichaelC> worth getting feedback on concepts
<david-macdonald> can't hear you Alex
<Alex_> i'll have to dial back in
Lisa: In terms of list being new,
it was in the last draft as well, in the definitions available
from the SC. It was the same list. It's not so new. It was
similar to the second bullet in the earlier draft. It was
tweaked to address everyone's concerns.
... alastair spoke to how it was addressing personalisation, so
just asking for part of it, just one section of it.
<Zakim> MichaelC, you wanted to test ¨We´re almost there but need improved definition wording to approve¨
MichaelC: we have 5 min left on this topic, can we consider another approach to next steps? Not sure we have solid consensus for this yet, and it wouldn't be published this week in any case. Let's clean up on the definitions we know need work already, give it a chance to be socialised a bit more.
Alex_: I don't think this is ready, we need some more time, we need a new survey to look at carefully. Let's wait.
Kathy: Clarification, we have conventional names for three different categories, or is it English based?
markjohlic: Are we saying that these are the only words that could be used?
Lisa: We'll need to harmonise
them with HTML5 spec, but we wanted a very clear scope so
people knew what to do.
... these are programatic names, can use coga-semenatics, or
through controlled vocabulary, or other ways of meeting them.
Could do it in any language right now. Could be in the text
label as well.
Kathy: There are other conventional names, this is a US-English based list.
MichaelC: Encourage people to address comments on i18n and clarity, and get people to look at it in the next week, go for a decision next week. Is that a plan for the moment?
RESOLUTION: Partially clean up definitions and bring back next week.
<steverep> Can we please make sure to get the version desired to be reviewed in GithHub? Thanks.
<lisa> thanks :)
Detlev: Wanted to clarify, Andrew
is SC manager and we had comments from Greg about links in
lists, where they get very long. It's a trade off between
target size & usability. Thought we should allow for lists
to be closer together.
... the text in the survey doesn't take that into account. My
comment in the survey includes some text for that, maybe not
good text but initial idea.
... another thing addressed in the response was about the CSS
hack technique which extended inline target sizes. That lead to
the proposal to remove the AAA SC.
... There were concerns about older pages which wouldn't meet
it, so there are exceptions, including for blocks of text.
MichaelC: Does addressing that affect your view on the AAA SC?
Detlev: I'm not sure we should keep it. I'd like to keep it, but removing it addresses StephenR's comment.
MichaelC: 3 people didn't want to remove the AAA sc.
<lisa> +1 to cathy
Kathy: A lot of people would
prefer to keep it, but could live with removing. Concern that
at AAA you don't have links in paragraphs. But isn't AAA's
purpose to show things that are desirable, but may not always
be achievable? Yes, there is extra work, but that was the
point.
... that said, if it helps to get the AA SC in, then people
would prefer that.
McihaelC: So the AA version isn't accepted?
Kathy: No, was removed previously.
jasonjgw: I think my comment has been covered: AAA is for things that are not always possible but desirable, so I don't think the objection is reasonable.
<Zakim> steverep, you wanted to say that if we keep it, then acknowledge not using CSS negative margin technique
steverep: I'm ok with leaving the AAA version in, I'm just not happy with the CSS negative margin technique being in, that has issues. Two big issues: can't guarantee it wouldn't overlap, and messes with focus indicators.
david: There's an exception for blocks of text, so the negative CSS example isn't needed.
Kathy: It wasn't a technique, it was an example to show it is possible. Not required, no technique coming for that.
David: The missing thing is about the stacks & menus, left-nav bars. I think we need to go to 22px for stacked/grouped links in that scenario. (at AA).
MichaelC: Can we resolve the AAA SC?
Detlev: Happy to keep the AAA if
others are not objecting.
... for the stacked links, there are concerns around i18n and
different text directions, so need to be careful of
language.
gowerm: I assume we are focusing on the draft SC language, aren't the techniques the focus?
<Detlev> +1 to keep AAA
<steverep> +1 to Michael on implementability means there must be viable techniques
MichaelC: Yes, so long as there are techniques to fulfil it. We shouldn't block SC due to techniques, so long as we're happy they are feasible.
<Zakim> MichaelC, you wanted to ask who can´t live with keeping AAA version
MichaelC: a number of people have said they're happy to keep the AAA. Would anyone object to keeping the AAA version?
<gowerm> yes
<lisa> +1
MichaelC: ok, so we have a tentative decision to not drop the AAA version. I think we can circle back to the AA version and it's exceptions.
<Detlev> Correct
+1
MichaelC: we have a new exception from Detlev, what's the summary of that?
<Kathy> +q
David: When you have a stacked set of links, like a left hand menu, increasing to 44px tall will create a lot of scrolling, so want to make an exception for that, 22px x 44px minimum.
Kathy: One of the things we need to add, addressing Detlev's comments, and the i18n aspect: When there are groups of controls that will cause an increase in scrolling... if we had something to quantify the scrolling, we could then drop the size to 22/44px. There are situations with 44px across and horizontal scrolling we need to be careful of.
<kirkwood> +1 to Kathy
Detlev: We have discussed the figure +10 controls, but it's problematic. There are different screensizes, content management systems with varying numbers of items in each menu, it's quite difficult to put in a fixed figure.
<kirkwood> +1 to DetLev
Detlev: need to define a stack grouping, rather than a number of items.
David: Just don't know how you could evaluate it against a set screen size. Would love to get to it that way, just not sure how.
<david-macdonald> +1
Kathy: Don't want to have something with 22/44, when could be 44/22. How about at least 44px on one side?
<kirkwood> +1
<Kathy> targets in stacked lists have at least one dimension that is 44 pixels and the other is at least 22 pixels
steverep: We could use a cap on the total number of pixels in a list? E.g. 320px.
<Zakim> MichaelC, you wanted to say need to circle back on refined def for new exception?
<Detlev> +1 Fine with me
MichaelC: Does someone have a wording ready for today? Kathy's at xx.55:27.
<david-macdonald> +1
<Kathy> +1 fine with me
<marcjohlic1> +1
MichaelC: Any objections?
<Pietro> +1
Alex_: I think 'stack' means
up/down, rather than horizontal?
... in that case stack isn't the right word.
MichaelC: That's an open issue.
<david-macdonald> targets in grouped lists have at least one dimension that is 44 pixels and the other is at least 22 pixels
<Kathy> targets in horizontal or vertical lists have at least one dimension that is 44 pixels and the other is at least 22 pixels
steverep: Is the goal to not impede the authors ability to layout stacks?
<gowerm> How about just "targets in lists have at least..."
<kirkwood> if concern is to limit scrolling maybe we should just say that?
Kathy: don't want the user to have to scroll a menu. E.g. 10 links at 44px high is 440px, very high. We see it in vertical situations, but applies in both directions.
<Kathy> targets in a list have at least one dimension that is 44 pixels and the other is at least 22
<Detlev> @steve: It's too prescriptive
steverep: Need to define a total pixel dimension that doesn't impede it, and then tell author to maximise the dimensions within the list. cutting in half may not be necessary, it could be 32px high.
gowerm: I'd prefer not to have this exception because, for menus, it is a vital control. We have mechanisms for people to make things larger. Many of the exceptions are not for critical controls, whereas a menu is a critical control.
<Kathy> grouped targets with more than 5 items have at least one dimension that is 44 pixels and the other is at least 22 pixels
david: I think we need to explicitly say this is an exception. Making groups of links min of 44px is difficult. Language around the size of items could be different across evaluated. It's on every page, on every website.
MichaelC: I think we've agreed to keep the AAA version, and most people are happy with the AA version. But some work on wording needed for everyone to be happy.
<david-macdonald> Are we close enough for consensus in a draft? Only 3 meetings left before cutoff?
<gowerm> yes
<Detlev> +1
<david-macdonald> +1
<gowerm> +1 to note in editor's draft
Kathy: as we have to get outside feedback, and passed it once, can we include it with a note in the draft?
<marcjohlic1> +1 to editor's draft w note
<david-macdonald> grouped targets with more than 5 items have at least one dimension that is 44 pixels and the other is at least 22 pixels
MichaelC: For the public draft it wouldn't appear for a while anyway. Do people want to add it to the editors draft?
<david-macdonald> +1
+1
<Detlev> +1
RESOLUTION: Keep the AAA version of target size
Alex_: How do you mean open for exception.
<lisa> +1 to keeping the tripple a
<david-macdonald> grouped targets with more than 5 items have at least one dimension that is 44 pixels and the other is at least 22 pixels
<gowerm> +1
RESOLUTION: Accept AA version with editors note about exception for groups of links
Lisa: this started as a
modification of 3.3.4, so there does appear to be overlap.
However, some of the choices in there don't help people with
cognitive issues.
... there were three items that seemed acceptable, and Mike
suggested the basis for the current wording.
gowerm: The existing error
wording has: this is one of the three possible ways of doing
things. Anytime you are entering data to complete a transation,
you get a read-only view to confirm.
... normally you can cancel and go back and edit it. This is to
enable people to have a simple read-only version to understand
before submitting.
MichaelC: Is this intended to be merged during normalisation?
gowerm: could stay separate, allows for a different scenario.
Lisa: but then 3.3.4 becomes redundant, think it could be merged.
jason: my comments are in the
survey, but want to focus on definition of transaction, and
what is required in providing a read-only summary, and one of
the way to implement would be a confirmation step users have to
proceed through. That's a sig advantage to some people, but
disadvantage in real-time situations for other people with
AT.
... allowing people to review the submission is an important
principle, but the proposal doesn't spec the circumstance it is
appropriate for.
MichaelC: I think Jason's comments circle around defining a transaction, if that were clear then concerns about being too broad might be addressed. I thought it was clear, but seeing that it's fairly generic now.
Jason: that's about half of them, the others are what needs to be provided. E.g. could a tick-box undermine the read-only aspect? Also, imposing a confirmation step (one way of implementing it), will slow some people down in time-sensitive situations.
gowerm: some (a lot of) of that can be addressed in understanding. For example, github gives you a preview (read only) version, so that's a way to implement it. The transaction definition is a good idea, but we do have quite a few SCs that use it already.
Rachael: Can we setup a separate call for that definition?
MichaelC: Noted.
Mike_Ellege: please talk about the read-only aspect?
gowerm: The intent is that it's read-only, approve/cancel, final review with minimal complications.
david: This could be a huge ask, we want to balance benefit with change, as all forms are affected.
MichaelC: That ask depends on the
definition of 'transaction', we need to work that out.
... Alex mentioned this is an unrealistic change to an
established SC. If it were to merge into an SC, then it does
raise the alarm for Alex's comment.
gowerm: I don't have a problem with taking the wording from 3.3.4, and if you had a single-A version, you could meet this without meeting 3.3.4. So this is a more specific verison.
MichaelC: If we're clear it is separate that affects the evaluation.
Alex_: Agree with moving 3.3.4 to
single A, but not sure how you define a transaction that
doesn't make it a huge requirement.
... 3.3.4 is established, that can move to single A. Having
this as a separate thing on top of 3.3.4 just isn't doable,
except perhaps a triple-A.
Lisa: It might be more useful to go to other topic?
MichaelC: Who shares Alex's concern this is too big of an ask?
<KimD> +1 to David's comments
David: There's a trade-off, not a clear win.
<Detlev> I thought some new SCs might be merged anyway ?
<laura> +1 to David.
Rachael: If it were scoped to multi-page forms, would that change the answer?
<marcjohlic1> That sounds more reasonable - multi-page req
<lisa> good idea
<Detlev> Multiple steps rather than pages?
<laura> single page would help.
david: wouldn't you end up with a lot of content for review?
<kirkwood> Multipage into one page would be helpful because it wouldn’t itme out on each page, david
<Alex_> has anybody used ERP system
<lisa> david, it is often, for example your tichet and hotel . o
<Alex_> everything is a transaction
gowerm: I see this as common practice now, for things which have legal implications, or deleting data. E.g. buying things from Amazon.
<kirkwood> +1 MikeGower aying not unusual, agreed
david: didn't realise it was limited to legal things, is that the case?
MichaelC: I heard that people were more or less favourable, but clearly the definition of 'transaction' needs refining. Also need to make sure the scope is clear, so it isn't every form. Is that ok?
Alex_: In enterprise areas, every action is a transaction, e.g. moving goods and materials.
RESOLUTION: Continue work on transaction definition and scope
MichaelC: There was a question about AAA proposals...
<Alex_> sorry have to run
Lisa: Some SCs from COGA were rejected at AA, we were hoping they could be considered at AAA, then the information would be available in the spec.
MichaelC: Any reactions? Question for chairs soon.
<lisa> not problems with testability
jasonjgw: It is question for chairs, but it is question of what the issues were. If it's about scope to content that is ok, but testability is a problem regardless of level.
<Mike_Elledge> bye
MichaelC: Chairs will need to
look at this, but not hearing objections, so let's figure out
how it could work.
... hopefully a chair will be hear Thursday, thanks for
approving one and reviewing others.
trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/In content implemented using markup languages, the conventional name of conventional user interface components can be programmatically determined. (AA)// FAILED: s/In content implemented using markup languages, the conventional name of conventional user interface components can be programmatically determined. (AA)// Succeeded: s/In content implemented using markup languages, the conventional name of conventional user interface components can be programmatically determined. (AA)// Succeeded: s/w="w3c-wai-gl"// Succeeded: s/spoke ot how/spoke to how/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** FAILED: s/In content implemented using markup languages, the conventional name of conventional user interface components can be programmatically determined. (AA)// Default Present: AWK, KimD, JakeAbma, Laura, ChrisLoiselle, JF, steverep, jasonjgw, MikeGower, Greg_Lowney, Melanie_Philipp, Makoto, dboudreau, Detlev, wayne, WayneDick, chriscm, lisa, bruce_bailey, MichaelC, Rachael, kirkwood, marcjohlic, Pietro, jon_avila, alastairc, JMcSorley, David-MacDonald, Kathy, JanMcSorley, Katie_Haritos-Shea, Elledge Present: AWK KimD JakeAbma Laura ChrisLoiselle JF steverep jasonjgw MikeGower Greg_Lowney Melanie_Philipp Makoto dboudreau Detlev wayne WayneDick chriscm lisa bruce_bailey MichaelC Rachael kirkwood marcjohlic Pietro jon_avila alastairc JMcSorley David-MacDonald Kathy JanMcSorley Katie_Haritos-Shea Elledge Mike Regrets: Denis_Boudreau Glenda_Sims Jake_Abma EA_Draffan Bruce_Bailey Mike_Elledge Chris_Loiselle Kim_Patch AWK Joshue Found Scribe: alastairc Inferring ScribeNick: alastairc Agenda: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0370.html Found Date: 25 Jul 2017 Guessing minutes URL: http://www.w3.org/2017/07/25-ag-minutes.html People with action items:[End of scribe.perl diagnostic output]