See also: IRC log
<AWK> +AWK
<scribe> scribe: allanj
awk: bruce - control contrast. do we think that default browser focus is good enough.
<alastairc> Difference is that the focus isn't there until you focus, LV people need to have the border there to see it in the first place.
awk: if SC, focus had to have 4.5:1 and UA don't support, and authors can make change. can we set expectations that authors should make it better
glenda: reasonable expectations that developers do it.
<AWK> Glenda: especially since it is set in one place (CSS)
<JF> +1 to Jim
<AWK> Jim: if dev can they should
<laura> JA: Authors can make it better and worse. They should make it better.
Jim: browsers fail in focus contrast. devs can make it worse by turning it off, then they should be able to make it better.
<Glenda> oreo method can contrast with any background http://www.glendathegood.com/a11y/lvtf/textinputborder.html
<Joshue108> JA: If we set focus as 4.5:1, then thats what it is and the authors do it.
<Joshue108> JA: If the user wishes to do it is their prerogative.
<Joshue108> JA: There needs to be a base for the author to start.
<laura> JA: If we set 4.5:1 it will meet the needs of a big majority of users. Then the user can apply their own CSS if they want to customise it.
alastair: can lv user see a
control without giving it focus? then there is question of line
border
... what is a minimum thickness and at what contrast
<Glenda> here are some failure examples I created for 1 CSS px width and 3 CSS px width
<AWK> Alastair: first question - can a user identify an item when it isn't focused?
<Glenda> Failure examples: http://glendathegood.com/a11y/lvtf/submitbuttonbordernota11y.html
alastair: if you have input button with no border, user doesn't know it is a button
<AWK> ... second question - what level of contrast is needed when it isn't a text-based control
alastair: what is minimum border at what contrast so users can see it?
DM: double border, center is transparent.
<alastairc> AC: If you're LV and zoomed into a page, you need to discern the border to find the input, so focus styles are not relevant to that. Secondly, is 3:1 enough contrast when it is a line? (compared to reading text).
<Glenda> Go look at these 3 failure examples http://glendathegood.com/a11y/lvtf/submitbuttonbordernota11y.html
gs: is 4.5:1 and 3:1 based on line thickness is good failure point
<Zakim> JF, you wanted to say we're delving into techniques...
awk: if the browser has a visible focus, is that ok? or should we require more contrast
<alastairc> I would be happy to ask for something more-conrtasty, we have no leverage over the UAs except via web developers.
dm: requiring specific contrast will be tricky.
<alastairc> Note that the user-agent focus styles are being separated from outline, early stage but promising.
marc: for interface control,
happy with contrast contrast requirement.
... not sure about focus. let UA and user CSS
<alastairc> Also: Note that the user-agent focus styles are being separated from outline, early stage but promising.
<ScottM> someone has a cat purring
jf: native presentation of author
content should pass contrast requirements.
... if dev sets a background color, then they need to change
the outline
<alastairc> I can outline my previous thoughts: https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/, just afraid of the noise here.
awk: implementability and
techniques. is it too hard to do.
... there are more complicated UA dependencies. What is too
much for authors? how to manage expectations.
... for focus - here is the bar, then user free to
change.
... Lisa - personalization
<Glenda> David, can you check out the multi-border method I just created at this location (scroll to bottom of the page) http://glendathegood.com/a11y/lvtf/submitbuttonbordernota11y.html
ls: UA support, is not just AT support.
<AWK> Lisa: User agents aren't just AT
<AWK> s/
ls: UA is browser, extensions, and other things.
<alastairc> To noisy here, could someone read this out? I think there are 4 general levels... there is UA/AT that can adapt a site without the authors needing to do much except not cause problems (adaptation), and there are adaptions that need the author to do things to enable it (customisation/personalisatoin).
<alastairc> The effort required is fairly different, the LVTF ones generally fit under adaptation.
awk: need ensure understanding that not all UAs have the same functionality. if 1 UA has high contrast focus, and others dont, they could base their claim on that one browser.
<Zakim> JF, you wanted to read aloud Alastairs comment (on his request)
<alastairc> NB: Thst's two of the relevent levels, I outlined the others in my article, but not important here
jf: agree with Alastair. what can we expect from the UA stack - OS, browser, extensions, AT, etc.
<alastairc> thank you :-)
jf: how much does author need to do ... or not to do!
ls: worded SC on personalization - techniques have a burden. ???
<AWK> talking about https://github.com/w3c/wcag21/issues/6
ls: ask to authors to expose
context and accessible properties.
... figure out what is not covered by other SCs
<alastairc> Lisa_Seeman: Is there more to it (personalisation min) than adding metadata? If the meta-data causes icons to be added, surely you also have to customise the layout?
<Glenda> Oh…look! A triple-decker orea with red frosting filling http://www.glendathegood.com/a11y/lvtf/submitbuttonbordernota11y.html
<Glenda> triple decker oreo (black cookie with red frosting) http://www.glendathegood.com/a11y/lvtf/submitbuttonbordernota11y.html
ls: create something that is less burdensome for author (coga script/extension) or more work for user
awk: there are personalization
criteria being worked on in ARIA. should be fpwd soon
... is that enough for inclusion in AG
<Zakim> JF, you wanted to ask about "Critical" - who and how is that defined?
ls: ARIA and W3c 2 implementations (extensions on 2 different browsers)
jf: "critical" , what is critical - how is that defined.
<Lisa_Seeman> https://w3c.github.io/personalization-semantics/
<Zakim> later, you wanted to say that it is worth thinking about how what is expected in support personalization relates to the current 1.3.1 and to
ls: let us know if definition above is OK
<Zakim> MichaelC, you wanted to say personalization semantics seems to address mainly HTML, so we need approaches that work more broadly anyways and to say I think the personalization
jf: concern is how strongly we mandate this with A and AA. still very early in technology. not mature yet
<Zakim> AWK, you wanted to say that it is worth thinking about how what is expected in support personalization relates to the current 1.3.1 and to
mc: aria personalization if for html only. still evolving. not generalizable to to all web technology. need to word SC in a general manner
awk: you wanted to say that it is
worth thinking about how what is expected in support
personalization relates to the current 1.3.1
... what are the hook necessary for personalization tools to do
their job
... want to enable support for personalization. what
constitutes sufficiency. well established and mature
... concern about stability, and adoption of spec.
<alastairc> Not just stability, we can't tell how much effort is required to implement these new specs.
ls: to get enough content working
it has to be in the standard. chicken and egg.
... Create SC, so sites can use it, and browsers will make it
work
... how for are we willing to go. can we be innovative, or just
document what is already in use.
... or require author to provide personalization and build
their infrastructure.
... this all works with RDFa and coga script. but there are
issues
... or we do nothing
<alastairc> I'm trusting the need, but really struggling to work out the effort required on the author side, that's what we can't quantify yet.
<JF> +1 to Alastair - this is a scalability problem
<Lisa_Seeman> no it is not a sacalability problem, we have a lvely exptention script already for that
<Lisa_Seeman> one file per site
dm: like the coga idea. critical features (coga techniques) programmattically determinable.
<alastairc> Lisa: is it just adding attributes to the page, or does the author need to do more for the layout etc?
<Zakim> MichaelC, you wanted to say standards and guidelines are inherently conservative and to say and if overly aspirational they can fail to meet their objective and to say we won´t
dm: are we trying to get a wedge to raise awareness, or force authors to do LOTS of work.
<AWK> Michael: Standards need to be built around what is known to work in most cases
mc: standards are conservative. can't be aspirational. Must spec what we know works.
<JF> +1 to Michael, and to note that the current mood at the W3C AC is that aspirational goals are being quite frowned upon
mc: in wcag2.1 can solve all problems. why we have silver and perhaps 2.2
ls: we agree that it is implementable. at what bar. the author just has to add semantics. then the UA or extension does something with the semantics.
<JF> Question: can "relevance and information for simplification" be achieved without the use of COGA-* attributes, for example through the use of the @title attribute?
ls: I think with the current
wording it should address the issues.
... looking for guideance on whats the bar?
... SC is only about critical features.
... can create a critical feature file per site. Benetech
hackathon. using an x-name pointer.
<Zakim> AWK, you wanted to say that it would be helpful to see what a a specific site (say w3.org) would need to do to fully meet the personalization semantics
ls: should help with author burden and scalability.
<alastairc> +1
<Zakim> MichaelC, you wanted to say add semantics can work but is it a realistic ask? and to say WG guidance will be fuzzy because there are so many tradeoffs to consider
<KimD> +1 to MC - very complex
mc: adding semantics is a lot of work. are there other ways to acheive same result.
<alastairc> Cautiously positive, slightly worried about invisible meta-data use, tends to get forgotten if it isn't visible. Would like to dig in more to the practicalities, will look at the semantics spec.
mc: guidance will be fuzzy, too many trade offs. have to build an understanding in the working group.
https://w3c.github.io/personalization-semantics/
jf: do you have to use coga attributes?
ls: or use RDFa.
jf: adding semantics is a lot of
work... witness microformats - failed due to amount of
work.
... for big site or companies with LOTS of big sites -
scalablilty is an issue.
ls: put this to survey. see what everyone thinks and what are concerns.
<alastairc> I would really like more concrete info on how it is (intended to be) implemented before survey.
awk: more to talk about.
<MichaelC> 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) WARNING: Bad s/// command: s/Lisa: User agents aren't just AT Succeeded: s/Lisa: User agents aren't just AT// 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, Glenda, allanj, JohnRochford, Joshue108, ScottM Present: AWK jasonjgw Rachael Wilco Wayne MichaelC bruce-bailey Jim_S AdamLund marcjohlic Greg_Lowney JF alastairc dboudreau MelaniePhilipp Laura JanMcSorley KimD Found Scribe: allanj Inferring ScribeNick: allanj WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 23 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/23-ag-minutes.html People with action items:[End of scribe.perl diagnostic output]