<AWK> +Jake
<AWK> +Alastair
<AllanJ> scribe: allanj
awk: welcome back, good meetings in Lyon
awk: more communication with silver. STF (silver task force) has some homework for AGWG
<alastairc> Email to the list about Silver task: https://lists.w3.org/Archives/Public/w3c-wai-gl/2018OctDec/0060.html
sl: walk thru prototype.
<jeanne> Email: https://lists.w3.org/Archives/Public/w3c-wai-gl/2018OctDec/0060.html
sl: 2 exercizes
... copy template and fill in with success criteria. aim to get
many iterations as possible. complete or incomplete
... please add comments with how the process worked, and
problems encountered
... provided examples in the email ^^^ above
... moving from WCAG to silver
... principles become TAGS
<Lauriat> Info architecture template: https://docs.google.com/document/d/e/2PACX-1vRgf85Z_NJ7HmF-UX992wLx0F-sCQyipL6USL9HTmvBOWtH53C78SVNjKI8kLTxl5UuYJbc7ImiGsB_/pub
<Lauriat> Example test draft of Language of page: https://docs.google.com/document/d/e/2PACX-1vQTeTyH3FQZ-qkt-UsyoePHV_joN_nDJy5CsMvit4GjKnbw9zsZljvGG-kU2ZTRP6bUEVJmdIWGc_PX/pub
sl: these are html files
... add other tags as needed
... guidelines become guidelines
... anything else becomes METHODS
... SC numbers fall off
<jeanne> Some SC are guidelines. Technology specific SC become Methods
dmcd: what is difference between different prototypes
<alastairc> one is the blank template, the other is an example that has been filled in.
sl: two different
prototypes.
... Guideline Short Name - reword (it is the handle)
... Short Description is the SC text
... Long Desc is the Understanding
... try to be as agnostic as possible
dmcd: not using a page base for measurment, using an environment.
awk: any other questions?
... none, SL must leave in 10 min.
sl: please send email with questions.
<Lauriat> Plain Language Template: https://docs.google.com/document/d/e/2PACX-1vQVTxM2r00NtcYhZJY6lN6xh_fuM9L2jnPZQJ2c59KiyA_-BcC2HkhKf0IxDod4qBunvPkXbhkCHuKq/pub
sl: will take input in any format (word, html, text, etc)
<Lauriat> Silver Style Guide: https://docs.google.com/document/d/e/2PACX-1vTNEIRmC8KjpYMk4APRTZIVl3AJj7XY7XiG0bDiQM4oLJueOFrpJUjbNY7fj9R41KLwjtBi8irIWclB/pub
sl: ^^^ rough draft. want to test how easy it is to follow. comments please!!
<Lauriat> Drafted plain language translation of Name, Role, Value: https://docs.google.com/presentation/d/1V_nYD27N6kx8gRha0rrdQK8aKyvg7kKXu6rs44We7IU/edit#slide=id.g44d9cf9fde_1_67
sl: ^^^ not ready for prime time. something to edit and experiment with while following style guide
dmcd: style guide -- many departures from SC. there should be a dialog about the style guide. should make sure we are all on the same page
mc: this is the start of the dialog!
dmcd: difference between reader and writer.
js: want dialog and comments
about your thoughts and concerns using the style guide.
... what works, what doesn't. need comments on the process.
ac: practical concrete exercise is helpful. interested in knowing stumbling block. loop back to make things better.
dmcd: need a comparison between plain language vs "legal" version (used in courts, etc)
js: asked lawyers about this
topic. regulators and lawyers want the plain language not
technical language for interpretation.
... use the plain language for things that will go to
court.
sl: even the easy ones can be difficult to convert to plain language
<Brooks> q
awk: helpful to review 4.1.2
(plain language)
... this does look as narrowly focused as 4.1.2. what are the
constraints?
<jeanne> Section Headings https://w3c.github.io/silver/prototypes/PlainLanguage2/SectionHeading.html
js: would be better to use what
was demoed at TPAC ^^^
... just do the "getting started" tab as a start.
... do other tabs if willing
awk: some will be easier than others. trying to find where there are challanges.
js: also critical is format for rest of getting started ... long desc, etc
brooks: very interesting.
... Question: are these going to be content only? any
discussion on including other part - AT, browsers, etc.
js: YES!
... this is the part folks are most familar with. easier to do
testing with stuff we know.
... want to add tab for users - where folks may run into issue.
working on other parts, not ready to show.
brooks: could include methods on how AT or browsers should parse the information. Not just content authors, but what should happen with the content.
js: on the Info Architecture
prototype... has specific METHODS for authoring tools and
browsers. call out issues.
... please suggest changes, or write a new one.
<Zakim> alastairc, you wanted to ask about and suggest next time we'll discuss this.
<Zakim> gowerm, you wanted to say Use headings to organize content
ac: discussed giving folks a few weeks on this. will review on the 20th. please reply to SL on thread. put SILVER in the title.
awk: next discussion might be after thankgiving.. perhaps not the 20th
mg: so grab an SC, and add to template, make corrections/modifications as needed. discusses wording wording with JS
js: what exactly makes it plain language. don't word smith. need feedback. what needs definitions. where is technical language, where is plain language
mb: may need a section on where
thing are subsumed. Perhaps a 'summary' section to list
references for this part
... heading is just another label. if working on abstractions.
how high do we go.
js: if you want to charge ahead in new territory.... go!
<Detlev> I do
awk: do people know what they need to do in the next few weeks? anyone not know what they need to do?
js: please reach out to silver folks with questions and comments.
awk: wiki page summary of
minutes
... avoiding reading through document on the call
ac: seeking consensus of the
summary...
... centralized editing - larger editor pool
... any objections?
... perhaps a CFC... invite editors. they would be only ones to
create new material.
... if we do 2.2 and silver, how many items per month. fast and
slow track
awk: see decision policy in
wiki
... github issues - lots of folks not comfortable in github.
trying to expand # of folks able to work in github
<kirkwood> seem good
awk: many paths and formats of input with final output being github
<Rachael> seems good to me as well
<gowerm> +1
<laura> +1
<JakeAbma> +1
awk: any questions or comments?
<Brooks> +1
<Detlev> fine
+1
<david-macdonald> +1
ac: perhaps don't need CFC
awk: AC and I will codify this
into a process, showing options, where editors need to be
engaged. what is required of an editor.
... that sound OK?
<Rachael> +1
awk: any objections?
dmcd: where with editor info be posted.
awk: in agwg or github wiki. will send a link
<alastairc> Decision policy draft updates: https://alastairc.ac/w3c/decision-policy_2018-10-22.html
RESOLUTION: Chairs will codify editor requirements and publish them
awk: review decision policy
draft. yellow and underlined are new
... reviews document
dmcd: how to move on after formal
objection? or prevent triggering a formal objection
... guess it is ok. presents scenarios. seems tied together
ac: review section 3.4 - was meant to clarify loggerhead situations and how to move forward
dmcd: moving on seems to trigger formal objection.
ac: will need to think about it.
<Zakim> gowerm, you wanted to say "If objections are received" should be "In an objection is received"
mg: +1 to david
... editorial "If objections are received" should be "In an
objection is received"
... other minor lang issues
awk: other comments?
<david-macdonald2> Scribe: david-macdonald
<david-macdonald2> Reworking issue number 3.4 to decouple the rare instance of "moving on" from the even more rare instance of a formal objection
<Brooks> q
<david-macdonald2> AC: The original sentence was added was to try to remediate the situation where somebody keeps bringing up the same issue with no new information. Need a mechanism to move on in that case. And then if there's this formal objection
<david-macdonald2> AC: I'll take it off-line
<AWK> "If an objection is received and the chairs do not believe it presents substantive new information, or it does not meet the criteria established for adding new normative content the chairs may decide to move forward despite the objection."
<david-macdonald2> AC: What if people make a formal objection
<david-macdonald2> Michael: perhaps it needs its own number for formal objection talk
<david-macdonald2> AWK: if someone wants to pursue a formal objection perhaps that needs to be in the separate number 5
<david-macdonald2> AWK: this document is more about the decision policy of the group and probably should go into all the details that the process document as around what to do if working goes on.
<david-macdonald2> Brooks: I don't have any language to recommend at this point but I do want to say that I hope this process for handling interaction with the group would not exclude from consideration ideas that are brought up in objection just because they don't match the ultra narrow scope of how the issue is been set up by the chairs or whoever presents it
<david-macdonald2> I found that there were a lot of good ideas that came into the discussion over the last year there were no hundred percent on topic but that were relevant that in the be dealt with presently but were excluded because they were not may be exactly what the thread was about all the related
<david-macdonald2> So I would hate to see objections disqualified because it did meet the artificial bounds of how it was framed
<david-macdonald2> They are overlooked I hope there'd be an active effort by the chairs to set up additional questions as an additional issue to be dealt with on its own
<david-macdonald2> AC: I would agree the through the scenarios that I think you may be talking about that initial scope was sweated chunky bit of the 2.1 process for the criteria for success criterion was defined
<david-macdonald2> And some of the comments on this process up they were to that effect as well. We need to explain perhaps what testability means in actual practice. Perhaps if we agreed to that in advance we would've had less confusion.
<david-macdonald2> We have a fairly big list of deferred items.
<david-macdonald2> AWK: I'm be confused about that one because I'm not sure that's what was intended. Sometimes you need to make a decision on something that's narrowly defined because that's what the group can come to a decision on. What is important then is to not forget the other piece that could be brought up separately.
<david-macdonald2> I'm not sure what we can do in this document to address that.
<david-macdonald2> AC: this document has a section on scope which should help with that.
<laura> May already be adressed? 2.2 is The Call will be for a single topic (C9)
<alastairc> The para starting "Additions to normative text such as new success criteria should have a pre-defined scope." should deal with that.
<david-macdonald2> Brooks: it's a Herculean task to manage this process. I respect the very difficult job of managing a pathway through without losing good ideas
<david-macdonald2> Just to make sure we have a process to discuss the separate issues without sending off to the next version right away
<david-macdonald2> I hope where have a process when those ideas that come in that are not defined in the scope that are important to capture
<david-macdonald2> MC: I think you're talking more about procedure than decision policy. What we need is a decision policy than the allows us to make decisions. You talking about making sure there is a procedure not to lose things. I agree we need a robust your procedures not alludes things and I think that Alastair went through some of them. Some of it may involve trust that we will in good faith come back to things that you put aside.
<david-macdonald2> Some of it will require ownership from working group participants to refine the proposal has been come up and needs to be reworked before it is revisited by the group.
<david-macdonald2> I don't think we with defined scope and then say nothing else can come up. We don't know at the beginning what will of arrived with at the end. If we knew that we wouldn't need the beginning.
<david-macdonald2> When I heard the term scope... We need those procedures and working group participants to keep things alive because we know that things can fall off the table. We'll need to work on procedures continually as chairs and that we have ways of recording them. We also understand that at times can feel that things are continually shut the decides because an audit scope and that becomes a big data and it's not in scope of the new topic
<david-macdonald2> Need to be aware of that and find ways to solve them.
<david-macdonald2> AWK: Alastair will create a clean changed. I'm not sure if we have that now were not but will need to do a CFC. People on the call feel that we are at the right point to to do that for there are additional things that people want to see
<david-macdonald2> AWK: an object to moving forward with what we have with any final edits and going to CFC
RESOLUTION: Chairs will finish any minor edits and routed the CFC for the decision policy.:
<alastairc> Code of ethics & conduct: https://www.w3.org/Consortium/cepc/
<david-macdonald2> AWK: other things from TPAC. We had a few discussions about behaviour that we should highlight here, it's an heading right before silver as a notes. We have some decisions out of TPAC
<david-macdonald2> S/deepac/TPAC
<david-macdonald2> Everyone should be familiar with the document on behaviour so that we end up with people who are interested in specific user needs can work without technical constrictions and people on the technical sides have more time to review the content
<david-macdonald2> In the future for content if revenue success criterion one of the things that people talked about was ensuring that we have all the different pieces in place so that there is understanding content techniques the success criterion itself and all the pieces are there which will help resolve some of the technical discussions and debates because either something
<david-macdonald2> can be done or it can't be done in those things need to be in place as part of the way that that needs to be demonstrated
<david-macdonald2> AC: we need to make sure that we have folks in the low-vision and cognitive task force who have been familiar with working with success criterion and the technical and standards aspect of those so if their homeland and collaborate upon before they come to the group that will be a big step in smoothing a process
<david-macdonald2> AWK: there are variety of other things in here but the part that I really want to make sure we talk about that we spent a fair bit of time talking about what we would do. What's coming next and thinking about Silver versus 2.2 but we need to finish up techniques for 2.1 and so we basically were coming to agreements that
<david-macdonald2> What we really want to do is for the next two months is focus on techniques a lot
<david-macdonald2> There are task forces that have been involved as well but I think given what we have coming up in that we are going to need to be charter so that come March we are going to need to start having greater clarity around what we are re-chartering for
<david-macdonald2> What I'm hearing from task forces is that for them to focus in on the updating gap analyses and making sure they have a sense of user research user requirements that we can then incorporate in the theory chartering process
<david-macdonald2> It is probably more or as much as they can do so that the working group participants will be focusing in on techniques. We want to make sure that before January we have one
<david-macdonald2> The other thing we need to talk about is an update to WCAG to ICT. We need a few people at least were willing to do a more detailed review.
<david-macdonald2> We need to have some more eyes on that. David has done a preliminary work on.
<david-macdonald2> The focus between now and January are those things. Techniques and WCAG to ICT, and task forces working on gaps.
<david-macdonald2> Is that a what other people recall
<AWK> David: couple things
<AWK> ... really want to get into Silver but get that we need to hit techniques hard first
<AWK> ... suggest really integrating with Silver effort in January
<AWK> ... have a concentrated month to help eval the viability of the concept
<AWK> ... people in Gov of Canada have expressed interest in using 2.1 but are concerned about missing techniques
<AWK> ... so we do need to do those
<AWK> ... open questions such as "can we do plain language?" that we need to look into more
<david-macdonald2> AWK: a technique came in this morning and if there are techniques that are coming in please let us know.
<david-macdonald2> AC: Detev created an issue at the top of the issues list
<alastairc> https://github.com/w3c/wcag/issues/529
<AWK> Detlev - issue 529.
<Detlev> it needs more work, other examples
<david-macdonald2> Any others that people feel they need some help withAWK:
<david-macdonald2> AC: Laura created one recently and sent it around a see where is
<alastairc> https://github.com/w3c/wcag/blob/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html
<laura> I ported the Icon Font Technique Draft over to GitHub:
<laura> https://github.com/w3c/wcag/blob/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html
<david-macdonald2> Detlev: am I doing this the right way by creating a new technique and get hub and then creating an issue pointing to it I would be better tomorrow to a pull request and work from that I'm never sure what the right passes.
<david-macdonald2> a/passes/path is
<david-macdonald2> AC: create your own branch which you've done. Regarding pull requests I would do that when it's ready for review.
<david-macdonald2> AC: it's probably better to use issue for things that are wrong
<david-macdonald2> Detlev: so should've gone into a pull request rather than an issue.
<david-macdonald2> AC: what is being accomplished by setting an issue
<david-macdonald2> Detlev: to steer people towards a to help
<david-macdonald2> AC: in my mental model up or request would be better for that
<david-macdonald2> AWK: a lot of people are not necessarily going to feel comfortable starting and github the way that Detlev has. If he had started as a wiki page it would be perfectly acceptable to create an issue I am working on this and I need more help and I need an editor who can get this into github.
<Detlev> OK
<david-macdonald2> AWK: maybe we should expect users to create an issue and then it becomes an editor's task to put intogithub
<david-macdonald2> AWK: my take is is it's fine
<JakeAbma> Will start picking up / finishing techniques I've been working on for next wek
<kirkwood> was it a security issue? raised? [just lost connection]
<david-macdonald2> David: I'm working on HTML type as a way to meet identify purpose on simple form fields that are about the user and the type matches the purpose
<kirkwood> I was responding to David around his question
<david-macdonald2> AWK: if we don't have anything to prove in the coming weeks will have to use the working call for that kind of work
<david-macdonald2> AC: I haven't been in process of dropping techniques. Issue 526 which from memory is adding positive type index values which is generally not recommended.
<david-macdonald2> I'm wondering from a group point of view in an editorial point of view if there any particular policies about dropping previous techniques
<david-macdonald2> AWK: I haven't read the issue can you summarize of further
<david-macdonald2> AC: the technique tends to contradict best practices by saying that positive time index valves can be used which can give screenreader users a strange order then before when you're narrowing through and tabbing through content
<david-macdonald2> Most people in the thread perhaps drop it as a technique.
<david-macdonald2> AWK: the testing for the technique seems to make sense
<david-macdonald2> AC: it seems like were giving up positive case for using a positive tab index which is the concern. In its time it was probably useful technique but with focus management these days we think most people would avoid that.
<laura> Maybe turn it around into a Failure?
<Zakim> gowerm, you wanted to say I have seen people programmatically use this technique successfully
<david-macdonald2> David: I'm okay with removing it but I've seen it used successfully occasionally. I would not want to see a failure in their.
<david-macdonald2> MikeG: I would like to see a deprecated tag on techniques that were not recommending any more. We don't need a technique in order for people to do a technique.
<david-macdonald2> May the discussion is that what we do when we have a technique that should be deprecated.
<david-macdonald2> AWK: we have removed techniques. The techniques are advice and we can remove them because we don't encourage a certain type of coding or practice
<david-macdonald2> And there presumably some techniques that we can take away for the same reason.
<david-macdonald2> The concern is that this is quite to encourage people to think that the desire how things are supposed to be done and I don't think there's anybody on the working group who would say that we should recommend using the tab index on a regular basis
<david-macdonald2> Brooks: we have the aria-flowto that can do that. If we don't have a positive tab index, we need something for cases where we simply can't change the code order
<david-macdonald2> AC: we don't want to say is a technique please don't use it
<Detlev> aria-flowto is hardly used / poorly supported (if things haven't changed recently)
<david-macdonald2> Brooks: we have this in the aria-spec, so we should have a cousin positive tabindex.
<david-macdonald2> +1 to detlev
<david-macdonald2> AC: if we make techniques dependent on one another nothing gets done so we need to make a decision on this technique. As a worthy of counting is working group advice or not or what it would take to make it so.
<david-macdonald2> We are out of time today but it sounds like we should look at this and give a bit of thought to it.
<david-macdonald2> Will send out a spreadsheet or what we think we need for techniques. Were looking for people to jump in and work on these things, and if you're good with JavaScript Detlev has a call for help in his issue.
<laura> thanks. bye.
<david-macdonald2> You have no problem
<david-macdonald2> no problem
<david-macdonald2> welcom
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/thankgiving/next discussion might be after thankgiving./ Succeeded: s/"In an objection/"If an objection/ Succeeded: s/We working/Reworking/ Succeeded: s/with/What if/ Succeeded: s/balance/bounds/ Succeeded: s/CSC/CFC/ Succeeded: s/Deepak/TPAC/ Succeeded: s/AC: there are variety of other/AWK: there are variety of other/ Succeeded: s/constant/content/ Default Present: AWK, Jake, Alastair, AllanJ, jeanne, Detlev, Rachael, david-macdonald, Lauriat, KimD, marcjohlic, JakeAbma, MichaelC, Brooks WARNING: Replacing previous Present list. (Old list: AWK, JF, Gowerm, Detlev, Ash, PatrickL, Wilco, Jake, DavidMacD, KatieHS, KathyW, MichaelC, alastairc, patrickhlauke, JaeunJemmaKu, Rachael, Detlev_, jeff, rafal) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK Present: AWK Jake Alastair AllanJ jeanne Detlev Rachael david-macdonald Lauriat KimD marcjohlic JakeAbma MichaelC Brooks gowerm kirkwood Laura Regrets: Mike_Elledge KatieHS EA_Draffan KathyW BruceBailey Found Scribe: allanj Inferring ScribeNick: AllanJ Found Scribe: david-macdonald Scribes: allanj, david-macdonald WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 06 Nov 2018 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]