<Detlev> if there is no scribe I can do it
<Detlev> scribe: Detlev
<AWK> https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2018
AWK: TPAC agenda not set in
stone
... (reads aganda) - much work to do on Techniques - so spend
time on Techniques there
... 2 imporant items: Process updates & improvements -
going to 2.2 or to Silver
<alastairc> Draft agenda: Techniques & understanding docs session (2 half days), Process updates and improvements, ACT rules approval, Next normative work discussion 2.2 vs / and Silver, Task forces catchup & supplimental guidance.
AWK: Spent time with Silver TF to
be up to date
... 1/4 of time each on Techniques, process update, Silver -
suggestions?
<JF> WFM
AWK: all agree with agenda?
... ACT rules approval - ACT TF update before TPAC, they look
for approval
<Mike_Elledge> Sg
AWK: so will turn that into agenda with times
AWK: survey about Face2face at
CSUN - objections it is very busy - pro side, many are there.
12 people agreed, some were against it
... question of which is the best day
<Ryladog> I will be there and would like Mon and Tues as well
<Ryladog> +1
<marcjohlic> Mon + Tues works well
<AllanJ> +1
AWK: plan ist to have the face2face Monday or Tuesday. Any feedback?
<Brooks> +1
<JakeAbma> +1
<Chuck> +1
won't attend
<JF> If we need 2 days, I think we should use them
<Kathy> +1 but may not be able to attend
<Mike_Elledge> +1 But okay if we are available for only part of Monday, Tuesday?
AWK: Put into calendar - people will be updated
AWK: David has revised WCAG2ICT, sent link to a draft
<Ryladog> Thank you David!
AWK: should be easier than the first time
<scribe> ...new SCs should be broadly applicable
UNKNOWN_SPEAKER: AWK had talk
with Michael and ALastair to asee what needs to be done to get
it updated
... please look at David's draft to spot anything else that
needs updating
<alastairc> http://davidmacd.com/WCAG/wcag2ict-21-discussion.html
alastairc: it is only the new criteria in that draft
Mike Gover: happy to participate in reviewing it
Mike Gower
AWK: good resource, should be updated
<AWK> https://www.w3.org/2002/09/wbs/35422/TechniquesforApproval/results
AWK: one new item plus one by Mike G
AWK: opinion split on whether it need more work
MikeG: version 2 seems better, something was missing in version 1 (?)
PR #473
https://github.com/w3c/wcag/pull/473
AWK: Turning off CSS may not be a
requirement if it is considered an accessibility-supported
technique
... first change was just to take out "turn off CSS"
MikeG: version 2 is clearer
<laura> 02 Aug 2018 LVTF Minutes: https://www.w3.org/2018/08/02-lvtf-minutes.html
<laura> Wayne's analysis: https://docs.google.com/document/d/1kvz0D3Au1R6c6q8iKZNH3KqyBt3d6WaJNUCwV35BDX8/edit?usp=sharing
<Zakim> Mike, you wanted to say I think css sprites create issues
Detlev talking whether the F87 is still valid
MikeG: there are issues if you go
into hight contrast mode
... with CSS background images
Mike: another user is adding speaker and caption via CSS
alastairc: 2 directions to
rewrite CSS: minor modifications, or replace all CSS with
own
... that category is the one affected
... Wayne Dick works that way
... Other thinkgs like browser search and restyling not well
supported
<laura> I think Shawn Henry also works this way.
<alastairc> Not common perhaps, it's a power-user thing, but for some that's the only way to make it readable.
<laura> Browser in-page find does not detect pseudo elements.
AWK: Wayne's indication of elements (dots before paragraphs) - that would override author defined CSS-generated content
Detlev: doubtful if actual impact of that technique warrants a common failure
<laura> The ARIA subgroup created access to generated content without creating ARIA parameters to reference this content.
AWK: Current state WG still sees
it as a problem and what to uphold F87
... does everyone agree?
<Mike> I don't feel qualified to make a call on this.
<Ryladog> I dont think we should remove it
<laura> +1 to update.
<alastairc> +1 to update
<AllanJ> +1 to update
<Ryladog> +1 to update
<JakeAbma> _1
<JakeAbma> +1
<marcjohlic> +1 to update
<Mike> +1 to update
<Mike_Elledge> +1
<Mike> I also suggest further investigation on whether it is still valid.
+1 to Mike
AWK: changes suggested: remove "turn off"
+1
AWK: removing all styles would equivalent to "turn off"
MikeG: good to turn off to test content
<Ryladog> And tools use that turn off fuction
alastairc: agrees that turn off is helpful
<Mike> I feel like I don't have enough info to answer this, either technically or from the LVTF perspective.
AWK: We do not require that all pages work without CSS
<Mike> But I was just making the point that "turn off" is a clearer test.
AWK: Have something like "a common way to test this is to turn off CSS" to avoid the suggestion that content must work without CSS
<laura> +1 to "a common way to test this is to turn off CSS"
AWK: thoughts?
alastairc: happy with that change
+1 from me too
AWK: Jim or Laura, any thoughts for LVTF?
Jim: Turning CSS off seems to work
<AWK> <p class="note">A common way to test this critieria is to disable CSS styles to view whether content remains visible.</p>
David: Clarifying that this method is targeted to that particular check
<alastairc> Add that note to the latest PR and it's good for me.
Brooks: agrees with David, may be
misunderstood - is there a use case for people overwriting
:before an :after ?
... one should be selective in what one wants to overwrite? Is
there a compelling use case for using custom CSS - otherwise
the burden would be on the user
<laura> icon font characters cannot be excluded for font-family changes if they are generated content.
AWK: similar to Detlev's point - Wayne has told us that custom styles can use :before to make it easier to disabmbiguate certain elements, like new paragraphs
<Zakim> Mike, you wanted to say if we investigate this and get a finding one way or the other, we can change. Until then, this change is low risk.
<alastairc> Three issues: 1. Sepraration of concerns, not separated. 2. People who override pseudo content to add things like heading levels. 3. People who override all styles in order to neutralise layout.
AWK: so if this makes the names of speakers dsappear it is a ptoblem
MikeG: we should retain the F87 unless we have concrete evidence that it is not needed
AWK: so do we agree to take out "turn off style information" and add note instead?
+1 again to that change
<Mike> +1 to change
<marcjohlic> +1
<JakeAbma> +1
<alastairc> How about: "A common way to test this critieria is to disable CSS styles to view whether the content inserted with pseudo elements remains visible."
<AWK> <p class="note">A common way to test this critieria is to disable CSS styles to view whether content added using pseudo-elements remains visible.</p>
<laura> +1
<AllanJ> +1 makes it very specific
<Ryladog> +1
<alastairc> +!
+1
<JakeAbma> +1
<Brooks> +1
<bruce_bailey> +1
AWK: reading change in test procedure in PR
Is that OK for people?
<kirkwood> +1
Bruce: is it a common way to test SC or to implement technique?
AWK: common way of testing the failure technique
<AWK> Check that non-decorative information presented by the content is available when the :before and :after styles are overridden.
AWK: content property not represented in check right now...
<alastairc> ...when the content property of the :before and :after styles is overridden.
<AWK> Check that non-decorative information presented by the content is available when styles are overridden.
sounds good to me
<Ryladog> +1
AWK: any objections`?
<AWK> the property
Brooks: thinking this through - a new badge for a product rendered as a CSS background image included CSS-generated text - am I not allowed to do that?
<alastairc> Getting towards "if it is non-decorative CSS content then it fails"
<Ryladog> I think the non-decotareive text cover that issue
Brooks: seems to require sites to work without styles
<laura> That has always been the case. It should fail.
alastairc: if it is pseudo content likely to disappear for some people so it should fail
JF: you can't do that Brooks
<Jon_avila> F3 fails background images
Brooks: image pulled in as background sprite - so if it is marked up with ARIA..
AWK: Points to failure to Failure
of background images
... not just or not mainly a problem for screen reader users so
cannot be solved with ARIA
<alastairc> How about: Check that information presented by the CSS content property is decorative.
AWK: is this ready to be accepted now?
<Ryladog> Do it!
alastairc: confused by the use of 'content' (property rather than page content)
AWK: gives context of the test procedure - possible to clarify by adding 'inserted' content?
<Ryladog> +1 to inserted content
AWK: go for 'inserted
content'
... any objections?
Brooks: still things this is
overly broad compared to the original failure
... focus on CSS-generated content?
<alastairc> Rendered version: https://rawgit.com/w3c/wcag/update-f87-AWK/techniques/failures/F87.html
<AWK> Check that non-decorative information presented by the generated content is available when styles are overridden.
Brooks: that is good.
AWK: will merge into Alastair's branch then merge that
RESOLUTION: Accepted as amended
Volunteers needed for scribing...
<david-macdonald_> scribe: david-macdonald_
AWK: we just got this in this morning but it's a change and we extensively discussed. We were just waiting for the example to be updated
If you look at the rendered version for those who did not check it out in the survey that basically the changes that are here are in this example. There was raised about it saying enter or space and that it was not modelling great behaviour because it was not including the role
And it was not doing everything we expect
<jon_avila> One thing I added was aria live. I can back that part out if people don’t like th addition
So we do have language in this technique that says user interface control still must Satisfy success criterion 4.1.2
Changes the example itself and the code that was shown in technique SCR29
Every lives not part of the test procedure so people shouldn't be too confused about it. It is just helpful edition.
AWK: what the people think?
<alastairc> +1, assuming it's had a second look from a QA point of view.
<AWK> https://rawgit.com/w3c/wcag/SCR29/techniques/client-side-script/SCR29.html
<Detlev> +1
<AWK> https://rawgit.com/w3c/wcag/SCR29/working-examples/script-action-on-div/
<bruce_bailey> +1
<laura> +1
<JakeAbma> +1
+1
<Mike_Elledge> +1
<Ryladog> +1
<AllanJ> +1
<kirkwood> +1
RESOLUTION: accepted changes to SCR29 as proposed
+1
<Zakim> Mike, you wanted to say I like John's suggestion to add "the" and keep it singular
<laura> +1 to adding "the"
<kirkwood> +1
<Chuck> +1 to adding "the"
<bruce_bailey> +1 to adding "the"
<Detlev> +1 singular for consistency
<Chuck> -1 to plural
Mike: we don't use interfaces across the standards. And this is one of the options at Leonie suggested in her email. Let's not set a new precedent let's stay consistent with our previous.
<Mike> i can live with either. Agree it could be wordsmithed more, but let's not!
<AWK> Proposed change to "Information and the operation of the user interface must be understandable."
<kirkwood> +1
+1
<Detlev> +1
<alastairc> +1
<JakeAbma> +1
<laura> +1
<Mike_Elledge> +1
<alastairc> https://www.w3.org/TR/WCAG21/#understandable
<Mike> +1
<Chuck> +1
<JF> +1
<AWK> Bruce: Information and operation of the user interface must be understandable. (move "the" from before operation)
<AWK> Proposal 1: Information and operation of the user interface must be understandable.
<AWK> Proposal 2: Information and the operation of the user interface must be understandable.
Proposal 2 +1
<Chuck> Proposal 2 +1
<Detlev> +1 for version 2
<JakeAbma> 2 +1
<kirkwood> Proposal 2
<Mike_Elledge> Proposal 1
<Mike> Proposal 2
<laura> can live with either
<jon_avila> 1
<AllanJ> 1
<bruce_bailey> either is fine
<Mike_Elledge> eh
<jon_avila> Sure I can live with it
<AllanJ> can live with 2
<JF> either WFM
<Brooks> either is fine
<alastairc> Either WFM
RESOLUTION: accepted proposal two as editworial errata on principle three
AWK: various themes and topics that came up throughout the discussion. Ultimately our goal just to set people's expectations is that we are going to be discussing this is one of the big topics that we have at TPAC about which changes we make and which ones we don't make.
There are a variety of opinions expressed and we certainly have room for improvement but we need consensus
Alastair sent out a review of the issues with potential solutions and Michael, Alastair and I have been talking about.
<Ryladog> The info that I put in a previoys survey, is it in here?
Alastair: There are a lot of suggestions. Some of them may be in conflict with each other. The biggest global issue is whether we should have centralized editing or distributed editing. It was more centralized we could potentially not use github for the editing or collaboration.
That one aspect of centralizing the editing process which would cascading into some other changes as well is probably the biggest one.
AWK: some may remember me complaining about the specific XML format we used to have in the way we editing. I spent a lot of time and XML spy trying to figure out the process to create our document. There were a number of excess self transformation files and it was totally custom and zero chance that anyone would be able to help submit an issue.
Some people asked why don't we just use HTML for format which flowed into how are we going to manage that, expose that information externally so that people can see it to make changes and log issues. That's where get up came in. It was becoming the tool of choice in the W3C and elsewhere and so we made the switch.
We may have been overly optimistic in our thoughts that other would be able to jump in and make changes. We can say that we do receive both requests from outside the working group and we have people within working group who have used get up enough that they're comfortable making all sorts of changes.
We also have many people in the group proves that it they are not comfortable using github and don't anticipate that they will have time to get up to speed with it because it's not part of any other part of their day-to-day job.
That's part of the context for it. I guess all we have to do is to mentally just go back to that situation where was Alastair Michael or me who are editing the content. It's possible that others might be able to learn the XML such as the supplemental guidance or the understanding document we could have someone else besides the chairs during that but it would allow us to use a wiki or a Google docs that's fine.
But at some point things out to get it to github, and would simplify things of the expectation if would be effect is done by the editor.
<jon_avila> Seems like that is already an option
AWK: I think through the 2.1 developing process that we made it clear that people could work through the editors to get things into get up so that they don't need to but I guess we'd be saying that the normal expectation is that editors would do that.
<alastairc> jon_avila - an option, but we were asking people to draft in git/github
It would be fine to put invisible request but would not be the normal channel.
AWK: the editors have infinite time :-)
<alastairc> AC: not!
<jon_avila> I always felt that editing was allowed in wiki or other format
<Ryladog> I prefer the editors control the content
AWK: there are number of concerns, for me, part of one of the other items is that the working group trying to do a defined and smaller bit of work in each round. If you have a cycle in the expectation is that absolutely everything will be.the ocean will be boiled. Then it's a tremendous amount of effort
But if you say work in it 4 things done, it's different. So if we can change our cadence so that we have more time or have a more clarify process that could mean that we might be doing less and it's okay. But if you expect everything to be exactly the same as it was in 2.1 and everything has to be done by the editors that would be a problem.
+1
<Zakim> Mike, you wanted to say that rawgit will make it better
Mike: my sense is that we've improved a lot on how we useGIthub recently using the raw git link is beneficial to a number of people. Personally now that I've gotten into it I find it very useful to have the github process
Then you don't have a lack of translation problem where everybody agrees but then when it's in a new format and looks a little bit more confused so I think it will be less painful going forward with get up.
To me the larger issue is the polling techniques in this survey not always clear on how to vote for them and I think that impeded us working towards consensus sometimes as were predetermined thresholds for how many people had to prove something before we deal with it.
<AWK> David: this is a technical standards and I was new to GitHub and learned it
<AWK> ... going back to the old way with bug trackers - it was painful
<AWK> ... whatever process chosen will be difficult
<AWK> ... having no req't for people to edit in GH but can still file issues is good
<AWK> ... we shouldn't give up on GH entirely
<Zakim> AWK, you wanted to say that one of the drivers is that we received many comments that developing within GitHub is not accessible to them
<Ryladog> +1 to David
AWK: we got a lot of comments that get up was not accessible to people. People in the group did not feel comfortable working in HTML as a way to draft proposals or to read them. So were trying to figure that out. RAW Git helps
<Zakim> alastairc, you wanted to say consensus is definately something to define / communicate better.
People want to be able at the things differently. Trying to figure out the right way and it's hard.
Alastair: thankfully I became chair after the difficult bit in the 2.1. In the success creatures were pretty well pinned down. But I do remember having a realization that was that if it didn't get consensus it didn't get in and it took a while for me to understand that. We need to find it and communicated it.
AWK: the decisions around consensus these he wants where we had a CFC and everybody just says yes that Josh Michael or I could easily see this clearly passes. But when it was not clear cut we were consulting with each other around that so that was not just anyone chair or editor acting unilaterally and I think it's desirable to be able to say yes consensus means numerical
<Ryladog> The old days for Consensus was, I like the "I can live with it" that everyone agree with the resolution
<Ryladog> CVA, Amaya....
<Ryladog> CVS
AWK: XML format we had to be able edit those documents and we had to be able at those separately. And Mike would run the XSLT processor that would then give us the editor's draft.
Then we started using get up with the XML files, and then we switched over to having the files being HTML instead. So it happened gradually.
<bruce_bailey> Old days we used a software-oriented bug checker online database
<bruce_bailey> It was only the editors that used XML per se
We started using HTML from before starting on 2.1 and started using get up to slightly before then.
AWK: I think we changed what we view is consensus in a radical way.
<Ryladog> I answered a different survey months back on the process
AWK: were introducing this now to get the conversation started and ask people to take a look at the survey again with what Alastair added as potential solutions and get people's thoughts on those.
<AWK_> David: Channels Gregg V
<AWK_> talking about consensus - GV's philosophy was to not have "votes" because it divides the group
<AWK_> ... that was the source of the "cannot live with" language that we use
Alastair: I'd like everybody to read everybody else's suggestions and to make comments about whether there recommendations are useful or not. The people who filled in the survey later often commented about what other people would put in. We need to come to consensus us to find the best way forward.
Micael G: I thought that there were processes and procedures early on that it difficult for us to reduce the amount of content. I was in saying that we should have votes or anything like that but if we got 60 success criterion candidates. If there is a method of establishing a threshold of buy-in before we get to the nitty-gritty of working through it and makes it a lot easier to get the consensus simply because you're reducing the number of [CUT]
Chuck: I do want to change years of how we operated. I find the cannot live with comes with a harsher result. The vote seems less harsh and passive way of coming to a consensus. I've never been a fan of the question who cannot live with.
However I do not want change years of how it's been working I just sharing my opinion.
AWK: when talking to come to
major conclusion today were just trying to kickstart the
conversation and to make people aware of what some of the
choices are. The big ask is to go through and take a look at
the potential solutions that are listed under Alastair's.
... let's move it up the question level.
Alastair: little concern because people started adding comments.
<alastairc> Only 8 people so far, please do review: https://www.w3.org/2002/09/wbs/35422/process-results-pt1/
AWK: we can move the comments along with the question about what should change about how the working group functions lower at TPAC. Does that sound reasonable to everyone?
+1
<Detlev> which are the TPAC days for the AG?
<alastairc> Mon/Tue
<Ryladog> Mon and Tues
<Detlev> ta
<AWK_> help needed:
<AWK_> https://github.com/w3c/wcag/issues/481 - what text from the cited section should be copied to 1.4.3/1.4.6?
<AWK_> https://github.com/w3c/wcag/issues/480 - accept these changes and seek out others?
AWK: we have a few things where we need people to help for a few issues that come up.
<AWK_> https://github.com/w3c/wcag/issues/478 - swap out stylish and stylus?
<AWK_> https://github.com/w3c/wcag/issues/476 - any concerns about reinstating links?
+ 478
<Ryladog> So do we want Stylish or Stylus?
<Detlev> Is there a link to Stylus somewhere?
<Ryladog> Can we send the link to the list when that happens?
<Ryladog> Stylus
<Ryladog> when we can add it. I do not see it
<Ryladog> yes
<Ryladog> thanks
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/Not comment perhaps/Not common perhaps/ Succeeded: s/power-suer thing/power-user thing/ Succeeded: s/president/precedence/ Succeeded: s/precedence/precedent/ Succeeded: s/to/two/ Succeeded: s/accepted proposal to/accepted proposal two/ Succeeded: s/not use get up/not use github/ WARNING: Replacing list of attendees. Old list: AWK alastairc Chuck JakeAbma Brooks kirkwood marcjohlic JF Laura Mike_Elledge Detlev Katie_Haritos-Shea Mike david-macdonald ! jon_avila 478 New list: AWK alastairc Chuck JakeAbma Brooks kirkwood marcjohlic JF Laura Mike_Elledge Detlev Katie_Haritos-Shea Mike Default Present: AWK, alastairc, Chuck, JakeAbma, Brooks, kirkwood, marcjohlic, JF, Laura, Mike_Elledge, Detlev, Katie_Haritos-Shea, Mike Present: AWK alastairc Chuck JakeAbma Brooks kirkwood marcjohlic JF Laura Mike_Elledge Detlev Katie_Haritos-Shea Mike david-macdonald jon_avila Regrets: Glenda Found Scribe: Detlev Inferring ScribeNick: Detlev Found Scribe: david-macdonald_ Inferring ScribeNick: david-macdonald_ Scribes: Detlev, david-macdonald_ ScribeNicks: Detlev, david-macdonald_ WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 25 Sep 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]