<AWK> +AWK

<scribe> scribe: allanj

Dependence on User Agents/Accessibility Support and what this means for WCAG SC

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: