<alastairc> scribe:Mike_Elledge
<scribe> Scribe: Mike_Elledge
<Detlev> we have internet problems will be late
ac: One person has resonded to survey
Making progress, lining up items, getting to publication
ac: Four peopel have responded.
<alastairc> https://rawgit.com/w3c/wcag/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html
ac: Provided by jake.
... Reflow definition, example, code and text procedure
... Matches reflow test procedure. 1080, etc.
... Three=ready. Marc Jolic had comments.
mj: Thought technique worked great. At very top, 1st sentience, add
"width equivalent"
mj: Though dicussins came in with SC, ahve seen times where between two points can get horizontal scroll.
ac: Good questin. In general,
reflow shouldn't cause horiz scrolling betw two points. It
would be a bug.
... Would rather have it in a specific way and then devs can
implement that.
... Best keeping it to what's closest to SC text. Then in
illustration shouldn' cause hs between 300 adn 400%.
<david-macdonald> Tighten up first sentence: The objective of this technique is to present content without introducing a horizontal scroll bar at a width equivalent to 320 CSS pixels, or a vertical scroll bar at a height equivalent to 256 CSS pixels for text intended to scroll horizontally. This is done by using layout techniques that adapt to the available viewport space.
mj: Can change vote on server.
ac: Senetence starting complex grid layouts probably not needed, goes beyond this scope.
mg: Text procedure needs
scrunity. two scenarios. #3 and #5 only deon if preceding one
is true. Put 3 and 5 into sentence in 2 & 4?
... If can't zoom in can do equivalent.
<AWK> +1 to Mike's suggestion
ac: Combine several points.
mg: 3 & 5 depending on if statement preceding them.
ac: What about horiz scrolling
that is usually vertical?
... Allows for that. Look to one final check that is true.
mg: A logic statement. Assuming wouldn't do 3 if 2 was not true.
ac: Yes. Might be more case of
"for" rather than ''if". Came up on client site recently. Had
one bar intended to be horizontal, but fit within 250.
... Covered in 2.
... Bottom of header is nav block, can horizontally scroll.
Rest of page works fine. Suggest adding button so know it will
scroll.
... Could be seen as failing for whole page. But not if
considering content block.
<AWK> "This is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance."
dm: All viewport in 320? Then how would it pass?
ac: Good question. Will try to remember why it might pass...
mg: There will be out-liers.
dm: Shlould get together and hash it out.
mg: Check 5 is true. Would have to fail that. 3 and 5 only carried out if prior line is true.
<AWK> +2 to mike gower's point
ac: Shall we take it as a thing to do in SC to resolve logic in test procedure.
<Zakim> gowerm, you wanted to say the test procedure may make more sense as 3 steps only
mg: Make 3 & 5 part of 3
& 4.
... will type in comments.
<gowerm> 2. If the text is read horizontally: Zoom in by 400%. Check that all content and functionality is available without horizonal scrolling.
<gowerm> 3. If the text is read vertically: Set the viewport height to 256 CSS pixels. Check that all content and functionality is available without vertical scrolling.
<AWK> "If the text is read vertically: Set the viewport height to 256 CSS pixels and check that all content and functionality is available without vertical scrolling."
mc: Description doesn't say what you need to do. Just "use grids". Helpful if links to good tutorials for using grids well.
<gowerm> Check #2 and #3 are true.
<AWK> (either way works for me)
mc: Linking to grids is useful, but not sufficient. Link to what user has to do.
<Zakim> AWK, you wanted to ask if we can have a % or CSS pixel dimension for procedure steps 2 and 4 to be consistent? Not sure if there is a reason that one is % and one is PX. Also, is
ak: Don't really need to talk. See comment in IRC.
ac: Following what mg had to say.
ak: My question is zooming to 400% other 256 pixels. Should be zooming in by 400% whether horizontal for vertical.
ac: lots of variation in height.
ak: Should be able to stress in same terms. Seems strange they'd be different.
ac: Can make that clearer.
det: Other techniques with "if"
type statments. Looks like linear sequence, but it's not. Seems
like it would have steps and subpoints.
... Can we format in if..then format.
ac: Suggestion to combine if and check. "For" text, wiht zoom bit first, then rest next.
<AWK> Example of tech with ifs: https://www.w3.org/TR/WCAG-TECHS/H30.html
det: That makes sense, simplifies things.
ac: Those ifs have check as part of statement. Can use that approach.
<AWK> In h30 all need to be true, but don't think that matters. This is different because it is forking of sorts
ac: More comments on grid
reflow?
... No resolution yet. Put back into draft. Suggest will be
same for next one.
... Technique #2...using reflow. First one applies to second
one.
ac: michael said needed more
discussion. Never user a feature they have to find.
... Not the CSS feature per se, have to other things to make it
successful.
... Can set text to 10 vh, that text would always stay 10x.
Would be a failure. Use media query to detect changes to text
size or zoom, then allow text to resize, or resize itself as
developer.
<alastairc> https://rawgit.com/w3c/wcag/tech-failure-viewport-units/techniques/failures/viewport-units-for-text.html
ac: If unlcear need to revise.
<alastairc> Please note: If media queries were used to adjust the size of text or unit of measure at different screen sizes, it may not be a failure of text-sizing. On-page controls provided by the author are also a way of passing the text-sizing success criteria.
mc: question about whether it
would cause conflict with css feature group?
... Read paragraph about not using viewport units, didn't see
note that revised that. Would move it up.
ac: So just take away read note?
mc: It's a short description, more could go into it, don't know what. Viewport units should be linked to definition.
ac: Height and width are also features.
MC: would like to add those. Don't know viewport, so seems like an example would clarify.
<Ryladog> Would there be definitions on viewport in UAAG?
dm: As soon as you see an example would understand.
mc: Should do teaching in
description, then have example to illustrate.
... Don't rely on example to clarify what you mean.
... Having a working example would be easy, so person doesn't
have to copy into temp page.
dm: A good failure, btw.
ac: Will expand description, link to definition, then provide an example.
ac: Ready for publication by all!
<alastairc> https://rawgit.com/w3c/wcag/tech-autocomplete/techniques/html/autocomplete.html
<AWK> link?
ac: Pretty much what it
says.
... Description based on 1.3.5. Name, credit card number,
expiration, etc. Fairly simple test procedure.
<AWK> should the procedure mention the attribute?
<AWK> or just the value?
katie: Wouldn't want to say put your cursor in the first field?
<AWK> How about: "The form field has a valid and well formed autocomplete attribute and value pair."
ac: Fraught. Depends on what person has installed. Some tool will tell you what value is. Assess if it's right.
dm: Probably will be automated.
<AWK> also "well-formed" instead of "well formed"?
ac: It is how you have to do it. but can't automatically assess.
dm: If I was a tool developer, I would.
katie: Question is if text is correct. Will come into play only when someone puts focus in field.
ac: Several ways. I select from
dropdown browser. Then select. Similar to alt text, ahve to
make visible, then can check.
... Should not fill out both me and spouse.
katie: Does your browser fill in without setting focus into a field?
<kirkwood> some plugins do it
ac: I think that's the native
browser approach.
... Have to put focus, but fills in whole form.
katie: In my experience, click in first field, then get option to fill in the rest.
<Detlev> @alastairc is that some browser plugin?
<AWK> But the point of the technique is that there are a variety of different behaviors that might result based on the attribute/value pairing, and that is what the technique is testing
ac: Lots of variety. Can't rely on tester installation.
<kirkwood> there are a variety of plugins that do it in different ways
Katie: My quesiton is that don't have to put focus into form?
<AWK> This is similar to https://www.w3.org/TR/WCAG20-TECHS/H37.html for image alt
ac: Also has option to put focus
into field. But don't have to.
... Add ak suggestion to test. Based on value pairing.
... One minor rewording.
dm: Will do now...
ac: other questions? As everyone else has approved, don't think new phrasing will cause issues...
dm: Need that endorphin boost!
<kirkwood> well done David!
Three cheers!!!
dm: New thing in branches that just includes technique in question.
<alastairc> Change step 1 to: "The form field has a valid and well-formed autocomplete attribute and value pair."
mc: Set up that way, but found that it couldn't be merged with other github. Mean that pull requests would say there were conflicts where there were none.
ac: Change...
<alastairc> Any objections to publishing the updated technique?
RESOLUTION: Publish the autocomplete technique as amended
ac: will do revisions to viewport
and previous items.
... Not sure how this came up. Increasingly difficult to test.
Silverlight is now unsupported.
... Flash going that way as well. Unsupported after 2020. No
new updates either.
... Do we remove techniques for them? Let's leave them in WCAG
2.0, but not include in 2.1. Not possible to use anymore still
have them at all in 2.0?
dm: Archive, rather than remove. To be cautious. Lots of Flash in ed world. Encounter more than I'd like. There are things that can be done to make it accessible.
ac: True for silverlight.
dm: Silverlight never came into mainstream.
kaite: Check with someone at MS.
ac: Tried that, some weblinks indicated that it's gone wrt MS.
<Zakim> AWK, you wanted to say that there is only one repository of techniques, so there is no keeping them for 2.0 and removing for 2.1. and to say that the overhead of maintenance seems
ak: Only one repository for techniques. Used to have a note for 2.0, but now just one repository. 2.1 is also for 2.0. Can't put them in separate places.
<david-macdonald> https://www.collectionscanada.gc.ca/whats-new/013-315-e.html
<david-macdonald> +q
ak: Someone can filter on 2.0, but overhead for maintenance is greater than benefit.
mg: Just to be clear. Can't remove techniques out of undertanding document?
ak: Can remove them. Show me all techs for 2.0, unless you uncheck box for Silverlight and Flash. But benefit is questionable.
ac: Technically not paying attention to Flash, so don't know if old techniques still work.
mg: Wondering if can branch between 2.1 and 2.0. Don't have a strong feeling although still see more Flash than would like.
dm: Still important information, but don't want to have if no longer work.
brooks: Agree with david. Do we have any kind of change log? Would help us if we had some sort of explanation of when removed and why.
<gowerm> +1 to the idea of a change log
mc: Commit history, but would be a challenge to have a change log and maintain.
Brooks: As a user would love to have a change log. Find techniques to be very helpful. Would be reticent if we didn't have some way to tell people of changes.
ac: Would overwhelm ppl if we shared all we change.
mg: Are techniques changed all that often.
mc: We don't change techniques very often when they're adopted. Would be easy to say that "x" technique has been removed.
<AWK> We could have a change log of major and minor changes - new techniques, removed techniques, particularly impactful edits would be major, most changes are going to be minor.
ac: Joined wg just before 2.1, are in phase of adding, might not be too difficult to add. But want ot keep high level.
mg: Maybe someing on techniques page.
ac: Look for items mssing on page.
mc: Could look on those things. But want to understand the effect.
ac: How techniques are managed...people still looking to keep them.
<gowerm> archive?
Katie: yes
dm: on the fence. Canadian gov't
has addressed, but put "no longer maintained."
... andrew closer to this than anyone else.
<AWK> actually we are all equally close to work on Flash these days
<david-macdonald> Archived Content This archived Web page remains online for reference, research or recordkeeping purposes. This page will not be altered or updated. Techniques that are archived on the Internet are not currently supported.
brooks: Be interesting to consider someone like me who is asked why things are done. If things disappear seems to underut getting ppl to do the right thing. May hurt those trying to help by not showing justificaiton.
ac: appreciate that. A how to
handle it kind of thing. First step would be something like
what david wrote above.
... Will discuss with andrew and michael.
ac: Keep official techniques on editor draft?
<alastairc> Overview page: https://www.w3.org/WAI/WCAG21/Techniques/
mc: Not editors draft. Official
public view, decided not to do for 2.1. Too hard to maintain.
If go to 2.1 to understanding takes you to a location that
parallels other support resources. Can style more easily. Now
considering what to do for 2.0.
... Discussing taht will take down and put where we're
maintaining things for 2.1. Want to avoid duplication, but
redirect could be confusing.
... Concern grows if 2.2. do we redirect from 2.2 to 2.0 to
2.1...maybe best approach to take number out of url.
... Would maintain backward compatibility. Silver likely to be
a completely different matter.
<Zakim> AWK, you wanted to having a general "WCAG" space for techniques - this will get to be a mess if we do WCAG 2.2, etc. The techniques apply to specific SC, and that is what makes the
ak: Good simple straight-forward plan that won't cause confusion.
dm: okay idea. Understanding changes for 2.1, will jsut update in 2.1 and 2.0 will piont to that.
mc: Same SC so merely additive.
dm: Would nto be change SC.
<laura> +1 to general "WCAG" space for techniques.
mc: If an edit allowed to do that
anyway.
... Not an erratum for 2.1.
dm: but have the flexibilty to do this.
ac: Have to be careful.
<alastairc> scribe: david-macdonald-2
<AWK> We can still develop new techniques for 2.0 SC, and we can still fix issues in techniques that apply to 2.0 techniques.
MG: what we have to do to redirects all of our internal tools to the success criterion
MC: we will try to take care of it on our and I have to check with the web master, that the plan a, Plan B is to put meta tags
Mike Gower: concern about cross-referencing
MC: we can look at that, but I still think it's better to do this than to have multiple similar copies floating in different directories
AC: if we don't do this than people reading 2.0 documents will have to find themselves in 2.1
Michael: we had to do this same thing and IBM. What you are suggesting is similar to what we decided if that helps.
AC: other business?
... looking at the Github cue
<alastairc> https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3A%22Ready+for+initial+review%22
AC: anyone have any other questions they want reviewed?
<alastairc> https://github.com/w3c/wcag/pull/457
AC: one from Detlev
David: I can take a look at it
Michael G: I can to
<laura> I can take a look at it
detlev: question about dismissible condition of however in focus. I don't know whether it's the right time to try to rephrase that or explain what I see as the problem
The other ones I think I'm understanding what I have to do. There are a few suggestions and other techniques. No big issues
<alastairc> https://github.com/w3c/wcag/pull/450
Deck failure on however focus is pretty far down on the list for review. I've put the questions in there as you follow that link. I think the main thing is that there is a condition that you be able to dismiss.
AC: my understanding is that you're worried that pure CSS pop-ups on hover or focus automatically fail 1.4.13 unless there some way to close them with the keyboard.
<alastairc> SC text: https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus
Detlev: my understanding expertise is that in many cases you get however content simply by having a hover or focus class and he would display something block that was hidden before. So it would be accustomed to that would work on mouse or keyboard. My understanding is that you should be able to close it without moving the focus or however
I can't see exactly how you would do that in us who had some script that you are registering pop-ups so that you'd be able to look if anything has been registered there and can be closed and with the script.
So it would mean applying a script. So my question is is that's what is meant by the success criterion or does it not apply to content that is simply created on focusing or offering Fayez CSS.
s/fayez/
AC: three ways to pass don't you sever focus provide the keyboard focus, or it is an input error.
Detlev: that would invalidate and make WCAG failures for any CSS only drop-down menu for instance for all those drop-down menus on focus or hover.
AC: yes, and I think that's the intent
<laura> Steve is on the call he was the SC manager.
Steve Rep: garbled
AC: is this SC counting out all the pure CSS drop-down menus, my thought is yes except for some extreme workarounds.
<steverep> I don't think that's the case... why would CSS hover be outlawed?
Detlev: acronyms in line, are expanded on however are pop up. This would also fail if it didn't have an escape, even though it is fairly limited in size and would probably be visible within the magnified viewport
AC in scenarios where you cannot dismiss the CSS hover content
Steve R: I don't think that it was the intention I would have to look into that closer why we would fail using CSS hover
AC: we don't know of any way to do that with the escapee if the trigger is pure CSS
Steve: Hmmm.
Detlev: getting back to that use case of small pop-ups which are basically working like title but are made more accessible but are pop up on focus. I see a deterioration of accessibility by ruling those because they're quite useful
You can't do it on click because in some cases the click would follow the link. In a sense would be a shame to rule out those types of usage
We can't change the success criterion but I'm wondering if there was some oversight and a drawback which we now have discovered and we need some sort of remedial action
AC: I thought it had been discussed and I have a sense of not being surprised by that outcome. In your case of the sort of acronym. We've always done that with a little script because we had keyboard accessibility with those types of things
Detlev: was activated on focus and hover?
So this would be a good case for a positive technique to how to do a simple offer pop-up that can be closed by escape because it's created by a script rather than pure CSS
AC: also I think the failure technique is probably good to go so that's the good news, ready for the next stage.
<alastairc> https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3A%22Ready+for+initial+review%22
<steverep> I'll go back through my notes for a possible technique
AC: any other questions on
techniques, if not I say let's take 30 minutes back and go to
that link and pick a couple of techniques to review. I think at
least two in 30 minutes for each of us
... Steve please continue the discussion on list.
<alastairc> 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/Resolution: Publish the autocomplete technique/Resolution: Publish the autocomplete technique as amended/ Succeeded: s/get up/Github/ FAILED: s/fayez// Default Present: AWK, alastairc, Laura, Chuck, MichaelC, Brooks, JakeAbma, Detlev, marcjohlic, kirkwood, Glenda, Greg_Lowney, gowerm, JF, david-macdonald, Kathy, Mike_Elledge, SteveRepsher, Katie_Haritos-Shea Present: AWK alastairc Laura Chuck MichaelC Brooks JakeAbma Detlev marcjohlic kirkwood Glenda Greg_Lowney gowerm JF david-macdonald Kathy Mike_Elledge SteveRepsher Katie_Haritos-Shea Regrets: EA_Draffen JohnF GlendaS JakeA Found Scribe: Mike_Elledge Inferring ScribeNick: Mike_Elledge Found Scribe: Mike_Elledge Inferring ScribeNick: Mike_Elledge Found Scribe: david-macdonald-2 Inferring ScribeNick: david-macdonald-2 Scribes: Mike_Elledge, david-macdonald-2 ScribeNicks: Mike_Elledge, david-macdonald-2 Found Date: 28 Aug 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]