See also: IRC log
<AWK> Scribe: Rachel
<Rachael> scribe: Rachael
AWK: Reminder that we are looking
to put the ACT framework out as a first public working draft.
We have had 6 people respond, all yes or yes with comments. We
need comments back next week. We will discuss next week. Please
take a look at the survey, read the editors draft and register
your thoughts.
... Evaluate for consensus on March 28th (ignore type in
email)
Wilco: We've addressed the
feedback that has come in and will continue to do so. The
survey closes on Friday so get your comments in. We want to get
some thoughts on the name of the document itself. We've had
concern about the use of the word Framework becuase it implies
something but we don't have a better word.
... IF you have suggestions, please include them.
JF: The survey shows 6 people have responded, 11 have not. Where is everyone else?
AWK: Because everyone is not part of the taskforce, the survey has been made public so the WG can respond. The 11 is the taskforce members.
JF: So anyone can respond, not just the taskforce?
AWK: Correct.
<Zakim> bruce_bailey, you wanted to ask about new items
bruce_bailey: Will we discuss the question at the top of the call?
AWK: We will get to it but
later.
... The COGA FPWD is also a reminder of an email you received
about an hour ago. There are some COGA documents that we want
to get out. They will not be normative. They are WG notes, but
please take a look at the email. The goal is to get public
feedback as it was with the 2.1 document. We will try to make a
decision in conjunction with the platform architecture APA.
Both groups have to agree its ready for FPWD. We will make a
decision the week of April 10th.
AWK: Github issue updating. I sent emails out last week. There are two parts, one in each email. If you are a SC manager, you need to go take a look at those steps. The best thing to do is to look at Issue #2. That is done and the model for what you need to do.
<AWK> https://github.com/w3c/wcag21/issues/2
<laura> 78 and 18 are also updated with the new links.
<laura> https://github.com/w3c/wcag21/issues/78
<laura> https://github.com/w3c/wcag21/issues/18
AWK: Notice at the top, there are links (SC for viewing, etc) This will allow us to link directly to the places in GitHub where the issues are edited and viewed. When viewing, you will hopefully see a page that will scale as needed. I have a list of all the Success Criteria that still need this added. I will send that out. Thank you to those who took this on already to get it done.
<AWK> SC managers needed for: 6, 7, 20, 27, 34, 37, 40, 44, 46, 52, 61, 64
AWK: This is related to Lisa's question at the beginning.
<marcjohlic> Two emails: Subject: "Task for SC manager" second email: "Second task for SC managers"
Lisa_Seeman: Instructions are in the email? Can those be put in a single email with a very clear heading to make it easier to find?
<marcjohlic> Sent on March 15th
AWK: The first one is quite long and I think people need it broken into two emails.
<laura> Andrew’s instructions: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/1200.html
<laura> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/1202.html
Lisa: I recommend a wiki page somewhere. People will need to refer back. Something with all the instructions. Or you may need to do most of the COGA ones.
AW
AWK: I expect people to look at
it and hope people can do it.
... Has anyone tried and had difficulty with the
instructions?
<Glenda> I am doing it right now, just by using Issue #2 as a guide
AWK: For many people, using Issue 2 as a model will be sufficient. If that is not the case, I tried to provide very detailed instructions.
<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_status
AWK: We talked about #1 and 2 last week. I have put together a status section for the success criteria
bruce_bailey: one of the themes is A vs AA. Do we have it written down what the A, AA, and AAA characteristics are. I feel like these are done by gut.
<bruce_bailey> this is the page I would like updated:
<bruce_bailey> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria
AWK: I don't think we have that
written as clearly as we woudl like. I think that there was not
as clear a distinction between A and AA in WCAG 2.0. I think
that is something that we should look at.
... Does anyone volunteer to pull together what we have? I
think we can defer that because we are discussing consensus at
all vs what level they are at.
... I think its a good point. One we need a better answer
for.
<alastairc> I have to duck out in a minute, but for 3. Adapting Text - we need the people who think it should be general talk to the people who think it should be specific (testable on the face of the SC).
Bruce: Taking an action item to create a draft of this.
<AWK> ACTION: Bruce to work on a definition of the a/aa/aaa levels [recorded in http://www.w3.org/2017/03/21-ag-minutes.html#action01]
<trackbot> Created ACTION-337 - Work on a definition of the a/aa/aaa levels [on Bruce Bailey - due 2017-03-28].
AWK: On the status page, adapting text is row #9.
<Zakim> bruce_bailey, you wanted to ask about A vs AA vs AAA
AWK: The questions that are in here are mainly around testability and implementability. I would like us to update the status page as we work on them.
<laura> +q
Alastairc: The question is around specificity. The way we were coming at this, if you as an author tested changing the font then you should find the issues that would appear to anyone changing to any font other than the one you specified.
<AWK> James, on https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results#xq10
Laura: rationale of the
hard-coded metrics was if it can't be tested true or false from
the SC text, it won't meet the SC testability criteria. If one
person tests with one font and color and another tests with
another font and different color, they will get different
results.
... Wayne summed up the concern in the low vision community of
having a hard metric value. Low vision people need flexibility.
Ideally we need both flexibility and testability. The point of
the SC is to avoid providing a mechanism. Low vision users need
to apply their own style sheet without authors introducing
barriers.
Michael: I get the reasoning behind wanting to specify a font but I don't fully agree with it. Understanding materials should recommend testing with a common font. If different fonts yield different results, then the SC is not accomplishing what it wants anyway. I would like to put the precision in the supporting materials.
<dboudreau> +1 to NOT specifying a specific font as well
wayne: I do think it should be stated in more general terms. You should be able to change font, font family and colors to what you need. I think it would be easier to sell to developers that way - they can see what the need is. As far as testability, you can pick any two colors with sufficient color contrast, any wide text font and it will work.
<Glenda> I agree. I think we can solve this with a sufficient technique. So the SC is more general…but we have a technique that gives us consistency in testing results.
wayne: The problem that can occur is seen in high contrast settings in operating systems in the last few years. They are inserting a lot of decorative images. That is the kind of thing authors can do to get in the way.
Wayne and James: Discussion of picking 2 colors as test vs testing all colors.
AWK: I can see developers where they would create a widget that would let them change the font to verdana. Not a great way to do this but if the font is specified, they would say they that they met the standard. Also, with internationalization, we want this to function for languages other than english so specifiying font.
<Zakim> MichaelC, you wanted to say Verdana is a vendor product and to say I wasn´t concerned about the other hard metrics
<JF> +1 to Michael C.
Michael: Verdana is also a vendor
specific product though widespread. I wasn't concerned about
the other metrics but I can agree with the need to make it as
soft as possible. Normally we ask people to make it more
testable but we are asking people to make it fuzzier.
... I suggest dropping the last part and stick with font
family.
<Wilco> +1 to don't be stupid in understanding
Discussion about what happens when change to a font family that isn't supported by teh language. Need to add some language about that.
Wayne: I will start working on some tests that come out true or false.
<Zakim> bruce_bailey, you wanted to ask if change to a sans-serif font?
Bruce: can we just specify a san serif or serif font but I don't know in the Arabic languages if that is a thing.
<laura> White on black was chosen because if that combination works, 99% of all other combinations should be able to be overridden.
Lisa: I think we've lost track of
the wording on this one. With the current testability
additions, we've lost the COGA use cases and we are relying on
this.
... We need line spacing. I want to send this one to the COGA
task force. If we go with the specifics, we need a font family
that works for COGA as well as the line height and foreground
and background. We may need a space between graphs as well.
<Zakim> Greg, you wanted to say It sounds like people still disagree on whether this SC should require web pages to ensure their text can be customized, or merely to remain usable when and
<Greg> Lisa, Andrew, have made comments that make it sound like they think this SC requires web pages to support the specific configuration listed, but in reality the configuration(s) listed is merely testing instructions to verify that the page has the flexibility to accommodate a wide range of configurations.
Greg: This SC is not about a specific set of fonts, etc. Those are test instructions that ensure that more flexibility is provided. Do we have consensus that those are just test instructions?
<Zakim> MichaelC, you wanted to remind this is about *these changes* don´t cause problems, but other SC may be at play and to say I get what GL says but the SC will read otherwise to most
Greg: Is there anyone who is not interpreting the SC that way?
Michael: I think most readers will interpret it that way. Most of us know what you are trying to do. I agree with Lisa that the specifics themselves need to be accessible. I'm expecting this SC to interrelate with other SC. The more specific this is, the more tricky.
<laura> +q
Wayne: Should the SC be reworded to make that clearer to readers?
<AWK> https://github.com/w3c/wcag21/issues/78#issuecomment-286442673
AWK: I was trying to reword it,
when you create a webpage there is a mechanism that allows the
user to adjust the technology. Either it works with an
exisiting technology or build in a widget (not ideal but
allowed).
... My suggested rewrite is about making this SC about adapting
text vs. specifying parameters.
<laura> Not about creating mechanisms. It is about personalization.
<Greg> Andrew, I agree but also explicitly requiring the web page to still be fully functional when the configuration is changed.
AWK: I think line and letter spacing is better than the other two.
<Wayne> +1
Laura: We had it more general to begin with and got pushback that developers would have to create widgets.
<Greg> Authors only need to add widgets if they're using totally non-standard UI such as presenting their text as an image of text.
Wayne: I want to see this to be about allowing users to choose. We can work out tests that will be pretty accurate. Not 100% but we don't have that level agreement on every WCAG 2.0 item. We can write good tests.
Lisa: The way its worded now, if we have a white foreground and black text, they will not think they need to test.
AWK: Do you prefer the way I had worded it better? Last link in IRC.
Lisa: We are making this framework and offered to the Low Vision Taskforce to make it into a browser extension so that will exist. So if the concern is mechanism, we can do that. There will be a free download. That would be a way to make it testable.
<Lisa_Seeman> I like andrews wording better
<Zakim> MichaelC, you wanted to say to say some of AWK wording works better, but should be not ¨a mechanism exists...¨ but ¨there is not loss of functionality when...¨
Laura: White on black was chosen because it is easily overidden. The plan was to test with a bookmarklet which Alistair has already made.
<laura> Results of Bookmarklet Tests for Issue 78: https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78
Michael: I think Andrew's wording
comes up with the flexibility we are looking for.
... I want to reword that if the users avail themselves of a
mechanism it doesn't break.
<jamesn> (iOS for example()
<Greg> Laura, that's why as I said in my response that we should test with at least two different configurations, rather than one, to ensure that any one configuration is not hard-coded in.
AWK: If you have a tool that doesn't support changes?
<allanj> +1 to Michael
Michael: I thought this was that things don't break when you customize things vs. that you provide a way to customize.
James: I also read it as if the platform supports changes, the content needs to not that the platform must support changes.
<allanj> +1 to michael
<AWK> Current SC text: https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/sc/21/adapting-text.html
<david-macdonald> +1
JF: Andrew is leading this discussion in the right direction. I'm concerned about current wording. I object to defining a narrow test condition and including it in the SC. The SC should reflect the reasoning, the purpose that it serves. This helps with cases where the SC can't directly apply. I think the right approach is to push back against the objections that led to the current wording.
<interaccess> trackbot, start meeting
<KimD> +1 to Michael's interpretation and the direction of AWK's suggested lang
<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference
<trackbot> Date: 21 March 2017
JF: I think some people are misinterpretting it. I don't think the testability objection is viable. I have problems with current wording and objections.
<Jan> +1 to Michael and to the direction of AWK's rewording of the SC
<Lisa_Seeman> not what i said
jf: I am concerned that once we have the SC, we can build the widgets. I understand we have a chicken and egg problem. We need to get the tools circulated and in the hands of people before we standardize the tools.
<Lisa_Seeman> It is just one way to make it ready, lots of solutions can be made by anyone
<Lisa_Seeman> mainly the browser
<Lisa_Seeman> the bigger concern should be meeting the user need
AWK: Laura, it seems there are more questions on this. Are we looking at this as a requirement that these have to be possible but if you are working with a platform that this doesn't exist there is an exception or that the customization has to be supported in some way. Do you have enough feedback to work on this going forward?
Laura: We will discuss it at the low vision task force meeting.
<Greg> I think it's useful to talk about use cases. One is a pretty standard HTML page, which doesn't need to do anything. A second is a web page that includes graphical buttons, so it needs to make sure those are visible even when the colors and sizes are changed by browser settings. Third is a page that displays its text by drawing graphics into a live region that cannot be affected by browser...
<Greg> ...settings, and it needs to provide its own settings to adjust the colors, etc.
RESOLUTION: No consensus yet
<JF> @Lisa, I agree, but just because we make a SC does not mean that browsers will all agree and make changes to their tools - WCAG cannot mandate software vendors to do *anything* (sadly)
<AWK> Current text for this SC: https://cdn.rawgit.com/w3c/wcag21/change-of-content_ISSUE-2/guidelines/sc/21/user-interface-component-contrast-minimum.html
AWK: We have 12 ready to go, 2 has significant issues. Michael and I both had concerns about the readability of the SC. Michael did you have specific questions that you want to bring up?
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results#xq9
Michael: I don't have anything specific besides not being able to understand. Too many subclauses to make sense of.
AWK: Glenda, with this one, can you in people speak say what this is accomplishing.
<bruce_bailey> +1 to what MC says about needing a “thereof” in the SC text!
Glenda: Its complex. We are
trying to make sure that anything that is essential for
understanding that is visual but not text, has sufficient color
contrast.
... We have one applying to graphics, and split this off. This
is anything graphical that relates to the user interface.
Examples: focus indicator, radio button selected/not selected,
can you see the radio button? With apologies, in Gmail when I
want to star an item, I have dificulty seeing the star
outline.
AWK: To solve the problem for the star in gmail, this SC would have you making it...
Glenda: Thicker or darker.
<Joshue108> trackbot, draft minutes
<trackbot> Sorry, Joshue108, I don't understand 'trackbot, draft minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<allanj> contrast on star is 1.4:1
AWK: If it is thicker, it can ge away with a lower contrast ratio?
Glenda: yes. Large text is difficult to define. WCAG 2.0 went with 14 pt bold and 18tpt. Research shows these are approximately 3 pixels wide. We went with how WCAG 2.0 handleed text.
<AWK> Glenda talking about comment on GitHub: https://github.com/w3c/wcag21/issues/10#issuecomment-287120439
Glenda: The question brought up on borders still needs discussion. What is essential is also a great question but something we struggle with in WCAG 2.0.
Michael: I've worked on some possible wording.
<MichaelC> proposed: The visual presentation of essential graphical objects, border line, focus indicators, and selection indicators for user interface components has a contrast ratio of at least 4.5:1 against the immediate surrounding color(s), except for the situations listed below:
Glenda: It will take me sitting down with a few other people and make sure nothign got lost but I appreciate you doing that.
<david-macdonald> +1 It would simolify the SC a lot too
James: I have trouble justifying the ratio as 4.5:1. In text, you have to be able to read the text. In a border, you don't need the same level of readability. Using 4.5 ratio, limits designers. I think using a 3:1 ratio and removing the sizing requirements will better support designers and the needed support.
<adam_lund> +1 totally agree, 4.5:1 is too restrictive to designers
James: We need something.
Determining a border, is a lower requirement. For example, a
border around a text field.
... I know there are a lot of terrible stuff out on the web,
but usually its in the 1-2 range.
<dboudreau> I disagree that 4.5 to 1 is too restrictive for designers… it’s just a matter of working around some constraints
<david-macdonald> the star I think is 1.4:1
<AWK> In gmail the ratio is 1.67:1 for the star
Glenda: If you go to Gmail and look at the star, I can't see it. Its large.
<adam_lund> it's 1pixel wide, too
The star is 1 px wide and 1.67:1
<Zakim> Greg, you wanted to offer a rephrasing "All _important visual elements_ have a contrast ratio of at least x:y against their immediate surrounding colors(s), with the following
<AWK> Worth noting that we have a definition of "essential"
<Greg> The issues with this proposal can be broken down into (a) readability, (b) specific contrast ratios, (c) specific list of what those ratios should apply to.
Greg: I also added a proposed
rewrite for clarity. Moving the list of things to glossary
entry. I think its useful to summarize criticism: Readability,
specific contrast ratio, what are the specific list of things
the ratio should be applied to. It would be useful to break
these out into seperate threads.
... It would help us see when we have consensus on any
category.
<Greg> “including when the page is scrolled” is ambiguous.
Greg: Phrase: "including when the page is scrolled" is confusing and I'd like to see that reworked.
Lisa: There is a common thread
through many of the COGA criteria where we are defining what
the most important information is. "critical features",
"important information", etc. Should we get a subgroup together
to come up with clear definitions of three different scopes.
Level 1: High contrast, personalization, etc. I think we don't
want to address the same thing in different ways across success
criteria.
... Once you've got scope A, you know that includes critical
features. You can define them once and apply them to the
guidelines. Define scope and then SC managers can apply
them.
Glenda: I think the right approach right now is to use a term that works for low vision right now and then work the issue. I feel more comfortable with essential right now.
Lisa: I think its helpful to create a definition.
Glenda: I'm concerned about it slowing down.
AWK: I'm concerned that this is a
change from WCAG 2.0 where there is essential and
non-essential. May be better for Silver. Lisa - consider
working with Bruce on A, AA, AAA
... We had fairly extensive testing done around color contrast.
It can get dicey. Note: find earlier research.
<Zakim> bruce_bailey, you wanted to ask if we make exception for elements conform to 2.4.7 Focus Visible?
Wayne: The ability to find essential information (It is defined in WCAG), is important. I think designers have decided that a certain look is needed but I think as a group we need to push back. Its like wheelchair ramps. People use to think buildings didn't look right with ramps. From time to time we should push back on developers.
<david-macdonald> Quick test, This button has 3.2:1 contrast about http://davidmacd.com/test/button.html
<allanj> not everybody uses AT
Bruce: Does anyone disagree that the default cursor and focus indicator will be excepted?
<Glenda> Oreo selection inspired by Apple http://www.glendathegood.com/a11y/lvtf/textinputborder.html
<JF> +1 to Glenda - a default focus indication of black marching ants against a dark-blue background fails pretty much everyone...
<jamesn> is Chrome/Safari's one ok?
Glenda: The browsers need to better support focus. The focus indicator passes.
<jamesn> I set the following config preferences in FF (browser.display.focus_ring_on_anything;true and browser.display.focus_ring_width;5)
David: If we can simplify the contrast ratio, we should do so.
<jamesn> makes a really big focus indicator on anything
<allanj> authors can can change focus indicator in the browser. They can make it worse than the default (as in no indicator), or they can make it better. They have control. the Cursor for input fields is not in author control
<Wayne> Personalization
AWK: Does anything to need to be discussed at the Thursday meeting?
<AWK> thursday topic: User agent support - where to draw the line
Lisa: Personalization needs to be discussed but was discussed last week.
<allanj> Luminosity Brightness of Enabled/Disabled Form Controls using default browser styling http://w3c.github.io/low-vision-SC/luminosity-form-controls.html
Glenda: Quick item for future agenda: the clause about when the page scrolls, applies to all success criteria. Does the success criteria apply to all states of the page.
<alastairc> It would be good to define customisation vs personalisation, e.g. point 4 in here: https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/
<laura> bye
<AWK> 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/Thursday call agenda items// Succeeded: s/topic:/TOPIC:/ Succeeded: s/.me // Succeeded: s/Agreed,/Andrew, I agree/ Succeeded: s/JF: Andrew/JF: Andrew/ Succeeded: s/AWKL/AWK:/ Succeeded: s/problemm/problem/ Succeeded: s/The rational for the hard coded metrics was that it cant be tested from true or false, it won't be successful as a test critera./rationale of the hard-coded metrics was if it can't be tested true or false from the SC text, it won't meet the SC testability criteria./ Succeeded: s/without introducing barriers./without authors introducing barriers./ Default Present: AWK, jasonjgw, Rachael, Wilco, Wayne, MichaelC, bruce-bailey, Jim_S, AdamLund, marcjohlic, Greg_Lowney, JF, alastairc, dboudreau, MelaniePhilipp, Laura, JanMcSorley, KimD, Makoto, steverep, Pietro Present: AWK jasonjgw Rachael Wilco Wayne MichaelC bruce-bailey Jim_S AdamLund marcjohlic Greg_Lowney JF alastairc dboudreau MelaniePhilipp Laura JanMcSorley KimD Makoto steverep Pietro Glenda Regrets: EA_Draffan Shawn_Lauriat Kathy_Wahlbin Mike_Elledge Neil_Milliken Mark_Hakkinen Jim_Smith Jeanne_Spellman Found Scribe: Rachel Found Scribe: Rachael Inferring ScribeNick: Rachael Scribes: Rachel, Rachael Found Date: 21 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/21-ag-minutes.html People with action items: bruce WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]