Meeting minutes
<Chuck> Peer chairs, I have joined early if you are available to join and discuss the upcomming meeting.
Chuck: question to Kevin - progress with template
Chuck: Any new introductions?
<Chuck> Hi gregorio!
Introduction Gregorio Pellegrino
… auditing ebooks / websites among other things I missed
Chuck: announncements?
Card Sort Results
<AWK> +AWK
Chuck: if you have new topics, send them to chairs so they become future agenda items
<rscano> ciao Gaetano :)
Alastair: introducing Card sorting results - sorting outcomes into categories (refer to presentation)
<Rachael> https://
<Rachael> present_+
Alastair: :some things to consider: there is no "perfect" structure
… it is about best match - understand how people categorize it
… basing this on averages would go wrong - create random associations
… won't be using the exact result of the task, but helps in finding best structure
… how meta would it get (categorizing the categories)
… taggig will help but a good default structure will be important
… one hint was organize outcomes the way they will be used - but no one organized things by life cycle
… the biggest group use types of content as a structure
… another grouping was what to provide / not to provide
… so of this is fuzzy and could be in several groups
… another approach was type of interaction (keyboard / screen reader / pointer / voice etc)
… the soting tool allows to create a tree structure how things are grouped
… allows an interactive analysis of grouping ("dendagrams"?)
<kirkwood> can we have a one-sentence (clear & succinct) purpose statement of this exercise?
<graham> apologies that was me joining on phone while i had it on PC and the silly thing wouldnt let me mute, sorry!
Alastair: average categories like controls - some odd ones
… (please refer to presentation for details!)
<Chuck> no worries graham, glad you are here!
Alastair: a top-down approach could define one overall navigation scheme
… supermarket example: navigating by type of food, or Italian food
… interface-oriented vs. provision-oriented
<Zakim> Rachael, you wanted to discuss when Alastair is done
<Rachael> Silver Research https://
Alastair: the next step will be recommended categories with outcome sorted where you would expect them
Rachael: Silver research quoted UX professionals in a way that you know when to think about each - like by role
<Zakim> dj, you wanted to ask about next steps method (card sort?)
DJ: Like it - will the next step again be a card sort or something else?
<ljoakley> 123
Alastair: good point - need to discuss with chairs and propose an approach
<kirkwood> how we organize can make the information more usable for different audiences such as UX designers.
Ben: when I saw WCAG 2.X reframed in terms of job role it seemed to work only for a short time - because approaches to work change
<kirkwood> +1 to Ben
<Zakim> bruce_bailey, you wanted to ask about transition from slide 7 to 8
David C.: would action-oriented also be an option, a third alternative?
<Rachael> +1 to moving towards leading verbs in Option 2
Bruce: go back to slide 7 + 8
Alastair: : thinking about categorization of categories - dendagram results you get these two options (two people independently)
<bruce_bailey> thank you!
Alastair: interface-oriented vs.. provision-oriented
<Zakim> jeanne, you wanted to explain Bentley University results as applies here is that type of content is helpful
Jeanne: Background on UX pros study recommended reading
… question was how can usability be improved?
… organised by the needs of developers (because they use it most)
<TheoHale> I think the job/role classification is a moving target, we have a lot of shift in roles at Microsoft just within the last decade, when I started I focused on something that would likely be classified as UX Design... I do however see huge value in organizing by function as it would be more flexible.
Jeanne: since it is organised by user need, it does not match the understanding of developers
<alastairc> https://
John K: The perspective bridging designers/developers is great
… potentially missing is the "stick" perspective (legislation) - have enabled certain groups to push for legal action / standardisation
<bruce_bailey> Analysis of Pete McNally Survey link also in slide 3
<Ben_Tillyer> +1 to giacomo-petri
<wendyreid> +1 to giacomo
<mbgower> FYI, we tackled a lot of this at ibm using the exising WCAG requirements. So it's useful to see that effort along with others https://
Giacomo: Lifecycle can be quite different between designers/developers - same person or a team - the guidelines should have filtering option to make it easier for users to achieve their goals
… the process cannot be prescriptive
<jeanne> +1 to filters - we proposed using tagging
Chuck: closing queue
<wendyreid> +1 to filters, but where should we do the filtering
Gregg: these things are synergetic - go together - it's not just a list to tick off
<kirkwood> +1 to tags
<david-cox> +1 to tags as well
Gregg: everything may end up in multiple categories - tagging could be an answer, tagged version (informative) based on normative material
<Ben_Tillyer> Is crowdsourcing tags from readers of WCAG a possibility, so they could evolve over time? (Obviously would need moderating)
<Zakim> kevin, you wanted to comment that there can be lots of different ways to organise the content that we could potentially support
Dan: +1 to research quoted by Jeanne - grouping and tagging both important - like the top-level by type of content being assessed
Kevin: Lots of different ways to organs content - WCAG reorganization have been tried, that was interesting - other environments for working out are useful such as quicker that has tagging - content should be presented in different ways
<GreggVan> Tagging allows sorting by person's role, by element, by type of testing, and more - all at the same time and intermixed
<kirkwood> red
Wilco: It'S like picking the color before we know what we want from the car
<Chuck> David, I closed queue so we could move on to the other agenda items.
<Chuck> Feel free to type in your thoughts.
<david-cox> I'll just comment here: roles change over time, so I'd recommend the baseline categorization not being done by role.
<Zakim> alastairc, you wanted to comment on roles and how requirements tend to cross roles
Wilco: an outcome may be solved by different people in different ways (say who takes care of focus indicator, styled or default)
<david-cox> UX designer wasn't really a common role 15 years ago. Same with content designer.
<Frankie> +1 to content type being an effective way to organize content for WCAG implementors. I've written guidance using this approach several times now. Role gets tricky depending on the content type and organization.
Alastair: We intend to have tagging to have multiple views on same information - support that organizing by role is problematic, there is overlap - workshops show that role allocations vary across organisations
… if it is related to the interface / the thing you're working on, it is the most concrete (for developers)
Chuck: Will consider results of sort to craft an answer
<david-cox> Also, the ARRM is an existing method of mapping roles to WCAG. We could incorporate that idea into the formal WCAG document in the future. (https://
<david-cox> ARRM = Accessibility Roles and Responsibilities Mapping
Prioritizing Outcomes (https://github.com/w3c/wcag3/discussions/43 )
Rachael: will create an alternative version of results and send out link to that
Prioritizing outcomes - publishing discussion lat week was nit conclusive -
<TheoHale> +1, to David-Cox, we also don't have a formal testing role anymore at Microsoft though that does not mean we don't test. Tagging based on function seems to be the best scheme. Role does seem to attach maybe too much to web content or specific platforms.
Chuck: Reviewed prioritizing outcomes, hint was that those that had research were higher ranked
Rachael: Possible of publishing things earlier one suggestion was to publish something that would bring excitement such as a new color contrast algorithm
John K: Prioritizing by analyzing analytics - how often are outcomes most searched
<alastairc> If we prioritized by a usefulness/numbers thing, I'd rather use which issues are found most in testing.
<tburtin> +1 to John K idea
<kirkwood> or the most traffic on our site?
Gregg: We should be careful when looking for information guiding prioitization (WW2 plane example)
<alastairc> https://
Gregg: like analytics but needs careful use of result
<Wilco> https://
<alastairc> Yes, but which ones?
<kirkwood> +1 to Wilco
Wilco: we have an answer in out charter which asks with a representative set of outcomes with documentation for WCAG 3 - need to demonstrate different approaches
<david-cox> Basically, if it's some of column a, some of column b... what are column a and b?
Rachael: Pick sample cross category or several categories - both approaches would fit the charter
Chuck: this is quite abstract now - hard to get a sense of how that feels
David C: The discussion board for pro of outcomes there are 3 options - some need more research - should be push for that research to happen, since that will take longest
<Zakim> Rachael, you wanted to speak to reseasrch
Rachael: : Part of the plan is to take all those and coordinate the research
<alastairc> The research is in parallel, but *we* need start working on things we have the research for.
<david-cox> cool, concurrent but the research portion is somewhat separate
Rachael: it is concurrent to this and it will be driven outside this groups - people wh are interested can get involved
Chuck: Distinction between self-evident outcomes vs. research-based - evident ones can ba fallacies
<Ben_Tillyer> +1 to Chuck's thoughts
<david-cox> +1 to figuring out how to make self-evident items also empirically-backed
Wilco: it' a bit nebulous now - maybe proposal needs to be more concrete
Alastair: it is tricky - the proposal of top priority (outcomes that have solid research) - others suggested to four on outcomes that *aren't* covered now - so the could be split between covered / not covered
<Zakim> Chuck, you wanted to say that I don't think we back ourselves into a corner if we make a decision and decide later to change that decision
Alastair: color contrast? anyone having proposals for VR?
Chuck: making the decision early is good since the course can easily corrected
Rachael: Net we should pick one outcome and provide the rest (testable etc)
<david-cox> As long as there isn't an over-committment, then it's easy to course-correct. Might be tough to pause work on an outcome once it's approved / prioritized.
<Zakim> Chuck, you wanted to ask about the polls
Rachael: when we have done that we can next pick a group of outcomes and work on that
Chuck: Polls not mutually exclusive
<Chuck> Poll: Focus on 1) a diverse selection of individual outcomes 2) diverse modules 3) Something else
Wilco: clarification - what do diverse modules mean?
<alastairc> So taking a spread from the start, or focus on 1 module to start with (then get diversity later).
Rachael: representative sampling two ways. either individual outcomes like supportingn input / clear language / structure etc to get a cross section OR a diverse set of models but work on them modularly (all the text & contrast isseus
<kirkwood> 1
<alastairc> 1 as preference, but happy with 2.
<Chuck> 1, no objection to 2
<Chuck> Poll: Focus on 1) a diverse selection of individual outcomes 2) diverse modules 3) Something else
Gregg: Two aspects: how to handle different situations - known things or new things; the best things might be to look at a variety of types or kinds of outcomes rather than randomly pick them
<david-cox> 2
<dj> 2
<Rachael> 2 but happy with 1
<dan_bjorge> 2, but ok with either
<Bri> 2
vote: can't tell
<DanielHE> 2
<Wilco> 1
<ashleyfirth> 2
<david-cox> Rationale for 2: we should try out modules early, to see if it works for us.
<ShawnT> 2 but happy with 1
<graham> 1 - it means the module sorting conversation can happen over time and also means that templates for pages, scoring etc. can be tested and improved on a more varied test set
<JakeAbma> 1
<Azlan> 1
<Ben_Tillyer> 1.5 (happy with either equally)
<jeanne> 1 but ok with 2
<bruce_bailey> 3 -- mostly 1 but at least one module
<mbgower> 2, i think, but can go either way
<Frankie> 0 abstain
<laura> 1
<tburtin> Unsure.
<GreggVan> not sure i understand 3 maybe
<julierawe> Not sure
<jon_avila> 0
<ljoakley1> 0
Chuck: sems 50:50 for niw
<Poornima> 1, 2 is also fine
<Frankie> +1 to a little bit of both
Rachael: Maybe look at Bruce's suggestion
<dj> 11 1s, 9 2s (not counting secondary preferences)
Dan: Most people don't have a strong preference - anyone want to make an argument?
<alastairc> Suggest that we look for a module which has a diversity of outcomes?
David C: Good case for modular, because we haven't done that yet
<david-cox> can do a 'test pilot' module. Low stakes, more about trying out a process.
Chuck; The chairs could decide, of the group is split or has no objections
<alastairc> That's true, a colour contrast module would be quite biasing for a scoring approach and/or conformance model
<david-cox> fair points from Graham, agree
<dj> graham++
<Glenda> +1 to what Graham is saying..I prefer starting with a diverse list outcomes (I think starting with a module or 2 would be too narrow)
<Wilco> +10 Graham
Graham: very diverse selection is important because it gives us a better feel also for modules - we also need to get informed o scoring - something may work for a particular module, but not across the board - so to make sure it works across the board will be important
Gregg: we need to get a feel for what the structure will look like how the different types will look, how different areas will be handled, since some require a very different handling
… if we can drop color contrast but just use contrast (we are doing luminance)
<Zakim> Chuck, you wanted to change scribes
<Chuck> Poll: Focus on 1) a diverse selection of individual outcomes 2) diverse modules 3) Something else
chuck: reintroduce poll...
<graham> 1
<dj> can we add a neutral option?
<david-cox> +1 to Dan
<Detlev> 1
dan_bjorge: can bruce's proposal be in list?
<Detlev> 1 (I liked <grahm's argument)
chuck: okay, new poll
<Wilco> 1
<giacomo-petri> 1
<rscano> 1
<Detlev> 1
<JakeAbma> 1
<Azlan> 1
<Glenda> 1
<dan_bjorge> 3 > 1 > 2
<alastairc> Poll: Focus on 1) a diverse selection of individual outcomes 2) diverse modules 3) Start with individual outcomes and complete 1 module 4) something else
<Rachael> 3 but only slight preference
<david-cox> 3
<GreggVan> 1 plus overall structure
<dj> 3 then 1
<laura> 1
<alastairc> 1
<jeanne> 1
<graham> 1
<TheoHale> 1
<kirkwood> 1
<julierawe> 3 but only slight preference
<shadi> 1
<ShawnT> 1
<ljoakley1> 3then 1
<Chuck> 3, ok with 1
<mbgower> 3
<Ben_Tillyer> Changing from 1.5 to 1 thanks to graham.
<Francis_Storr> 1
<Wilco> Update, sorry 3 > 1 > 2 Can't disagree with Dan
<ashleyfirth> 1
<AWK> 1
<jon_avila> 1 or 3
<graham> haha ben
chuck: (1) seems to have momentum
<david-cox> 2.25 (jk)
chuck: second poll from earlier
<tburtin> 1
<Chuck> Poll: Should we focus on items 1) Covered in WCAG 2 2) Gaps on WCAG 2, 3) Something Else
<ljoakley1> 2
<alastairc> 3, I'd like to start with 50:50, then re-assess later.
<ashleyfirth> 2
<GreggVan> change option
<kirkwood> 2
<jon_avila> 3 a mix.
<Azlan> 2
<Glenda> 3, I'd like to start with 50:50, then re-assess later
<Ben_Tillyer> +1 to alastairc
<dan_bjorge> 3, a mix
graham: 50 / 50 , 3 or 4 of each
<Frankie> 3 a 50/50 approach
<Ben_Tillyer> 3, a mix
<david-cox> 3; 50/50
<Zakim> Rachael, you wanted to suggeset revise the poll for 3) a bit of both
<GreggVan> 3 a mix 50:50 is ok but 69:40 ok as wll
graham: good to see if anything breaks
<Rachael> Suggested poll : Should we focus on items 1) Covered in WCAG 2 2) Gaps on WCAG 2, 3) Pix a mix of covered and new 4)Something Else
<dj> 3 mix
<TheoHale> 3, I think we can make a mess right now and clean it up later.
<david-cox> 3
<Wilco> 2, mostly new stuff and/or things that need fixing in WCAG 2
Rachael: new poll
<kirkwood> 3
Chuck: finishing queue first...
<Zakim> jeanne, you wanted to say option 3 is pick the strong researc-supported and include some gaps
<GN015> 3 topic based, ind of from scratch, taking into account what is present in WCAG 2.x and closing gaps
<kirkwood> +1 to a mix
jeanne: Recommend we start with strongly reasearch supported -- which will be mix of both
<tburtin> +1 Jeanne idea
dj: Mix , but we should be clear that we are not covering all gaps or all needs at start
<Zakim> alastairc, you wanted to say I don't think we'll be picking that many, so we can filter by strong research.
alastairc: to Jeannes point , not like we will be starting with 50+ -- so we can include those with good research
<jon_avila> we want to do both so we can also show people what 2.2 would look like in a new model.
loriOkley: If we do not start with gaps, how do we avoid repeating gaps from 2.x ?
<kirkwood> cough… COGA … cough
alastairc: coga as gap would be very ambitious , but thinking of gaps such as one technology is not covereed?
… ex mobile, there a bits of gaps, but broad support..
Rachael: Point of including familar problems lets us start writing...
… if we pick as start something new will make it harder to get started
david-cox: Noting that mix will mean publication will be odd for people not following this process...
<alastairc> David - we have an establish 'maturity' process for signalling how complete things are, which should help with the confusion
david-cox: but publishing can be address later. We do not need to decide how to publish just to figure out how to proceed.
<Chuck> poll : Should we focus on items 1) Covered in WCAG 2 2) Gaps on WCAG 2, 3) Pix a mix of covered and new 4) Something Else
<graham> 3
<alastairc> 3
<Ben_Tillyer> 3
<rscano> 3
<dj> 3
<maryjom> 3
david-cox: there are creative ways to publish that do not block working. ATAG was example.
<jeanne> 3
<laura> 3
<ShawnT> 3
<david-cox> 3
<Rachael> 3
<Frankie> 3
<Wilco> 2 > 3
<tburtin> 3
<giacomo-petri> 3
<GreggVan> 3
<ashleyfirth> 3
<Azlan> 3
<Chuck> 3
<Bri> 3
chuck: poll item (1) is not just SC, but broader topics
<JakeAbma> 3
<Glenda> 3
<mbgower> 3
<jon_avil_> 3
<Detlev> 3
<rscano> Seems that 3 is THE answer :)
<dan_bjorge> 3
Chuck: Group is giving us a strong preference for option 3...
Card Sort Results
Chuck: not making resolution
<Rachael> https://
Discuss Outcome format and level
<Rachael> https://
chuck: there was an Outcome and Format and Levels, see link
<graham> one quick one, can i suggest 1.1.1 is part of the mix, it is the most complicated item (in terms of what it covers and scope) in WCAG 2.0 and may end up being 2/3 criterion?
Rachael: last week people signed up to try outcome using different formatting.
… We could take week to read over and discuss / vote over github...
… but if anyone wants live conversation now, please say so.
Glenda: I tried writing up "adaquate time before timeout" and it was not until I got to questions that I got to anything objectively measurable...
… with going on to optional replies, I tried who/what/where/why that wilco used. I liked question format.
… was also why to prompt chat gpt
Mike Gower: Only one offered was time measure. The others seemed too soft.
Glenda: I tried following directions, but I didn't get down to requirements and testable and normative stuff until last part of template.
… I could not avoid objective parts in question portion.
Frankie Wolf: I took on alt text since i have had so many audiences for that...
… i did not explore question format, but I found exercise and template worked well at start...
… The User Statement was essential to conveying meaning and think that may be a good way to approach.
… authors need to understand impact before they can work on fixing.
<Glenda> I love the Question format AND the User Need (I think Frankie is so right. The why is very important!)
Wilco: The what/why/where approach comes from ACT framing. The user story problematic from perspective of who decides?
<dan_bjorge> +1 to Wilco - it shouldn't be part of the normative statement, but should be consistently nearby
Wilco: lesson learned from ACT is that it is very easy for things to get complex, with branching. ACT rules had to scrap initial approach and reformulate approach.
<Glenda> Responding to Jeanne - I’m all about qualatative assertions. I love usability testing. So…when I said, “a driver’s license” that would be like “usability testing has been done with people with xyz disabilities”
<Zakim> alastairc, you wanted to comment on the question format, and whether we can have a normative section below outcome.
Wilco: But wrt Outcomes -- We have not settled if those are going to be normative or not?
alastairc: It would be straightforward to formulate timing as questions, but the way Glenda approach added much more than that.
… there is tension between question and the what/where need details.
<Zakim> jeanne, you wanted to respond to Glenda that if we restrict ourselves to only "objectively testable" excludes user needs. The car analagy is overly simplistic. We should not be restricting what user needs we can include by only accepting "objective testing"
alastairc: so top part, why is thing important , but normative part could be aimed at testers and be normative.
jeanne: Please see Glennda and my replies in IRC.
<Glenda> I want WCAG to be tech agnostic. I propose the questions (or assertions) for THIS PASSES need to be tech agnostic. We can do the tech specific in ACT.
jeanne: If we set ourselfs up to using testable statements we are going to have gaps like we do with 2.x...
<julierawe> +1 to Jeanne
<mbgower> We define testing to the degree we can, and extend qualitative assessments after that, IMO
<Zakim> Rachael, you wanted to normative
<alastairc> Glenda - I'd like WCAG to cover a wide range of tech, but to do so the guidance will need to be specific for particular platforms.
jeanne: We have very valid user needs which have qualitative response. We should not be testable as something that puts us in a box.
Rachael: We have a couple references for this discussion.
… I will put up GitHub discussion.
<Rachael> Normative vs. Informative https://
Chuck calls attention to time.
<Rachael> Nomrative/Informative Pros and Cons https://
GreggVan: I agree people keep repeating the same concerns...
… outcomes might be wrong word, "provisions" can cover testable but also not testable....
<Rachael> +1 to Gregg
GreggVan: if provision not adopted in regulation, what needs to be done is still preserved.
<TheoHale> I worry that it's not testable it will not be enforceable and will have less value. I would love to figure out if there is a way to capture what Jeanne is making without diluting the value of testable things that are clear.
<Rachael> +1 to Glenda
<Chuck> +1
Glenda: As we pick outcomes, it will be important not to pick simplier ones. We need some that are GOGA oriented which rely on assertions rather than objectives....
<kirkwood> +1
Glenda: the passing would be claims that organization did user testing or provided training or hired additional FTE.
<Ben_Tillyer> +1 to this idea
Glenda: Assertions are not perfect , but step in correct direction , similar to having a drivers license or not.
<david-cox> great note to end on
Review How-To Template
<jeanne> +1 Glenda
<graham> I like the idea right up until the point that it requires X or Y service, lots of smaller businesses would not be able to afford that cost, yet they may be "compliant" anyway.
WCAG 2.x updates (https://lists.w3.org/Archives/Public/w3c-wai-gl/2024JanMar/0017.html )
WCAG 2 stuff
Chuck: If you are here only for WCAG3, drop if you like
<mbgower> https://
Mike Gower sharing screen of project board.
Chuck: People are having trouble with screen sharing and scrolling, so thank you mike for warning.
Mike Gower: We sent out 8 new candidates for adoption last week...
… if we get feedback from AG that raise any concern, we put into "For discussion" with task force and make adjustments.
… Please work from bottom up, only 6 items.
Issue 1642
<alastairc> w3c/
mbgower: We want to have more about documentation required since "standard exit method" and other keystrokes are not well documented...
… 2.1.1 is just keyboard operable -- but quality of that not addressed by SC
[mike reads changed line in Understanding doc]
mbgower: Lots of conversation in PR thread.
… paragraph added responsive to issue raised in PR thread [which mike g reads]
mbgower: Any quesitons?
… we think guidance supported and aligned with normative language.
[mike reads from current understanding, litteral SC text]
… SC says keyboard operation must be possible, does not require documentation regarding keyboard operation.
<alastairc> So it came up due to the question: Shouldn't odd keyboard key commands be documented? To which the answer is yes, that's good, but not required.
On the repo is a link to wiki, one over from projects tab
… wiki includes 5 tabs at present , 1st being process...
… newest tab, at bottom, is a parking lot for issues to be considered for wcag 3.
alastairc: We are putting some advice (best practices) into the Understand....
… things like it is good to add documentation for keyboard operation, but not part of the requirement.
alastairc: Patrcik had some concerns in the thread. Any concerns from AG?
3560 anti-aliasing note
<alastairc> w3c/
[mike reads new paraghraph from PR]
mbgower: First paragraph is what was previosly, new paragraph address how thin fonts result in different contrast ratios than calculated from CSS color specified...
… this new paragraph adopted from Understanding for text contrast.
<alastairc> w3c/
alastairc: Content is from contrast minumum and enhanced already in Understanding.
mbgower: Wilco raised in thread that ACT rule uses screen sampling, not using CSS values specified.
<mbgower> https://
alastairc: In thread there was a concern raised that using screen sample results in content failing which might have passed before , as anti aliases make text fuzzy.
mbgower: Overall we looking for alternative in PR thread.
alastairc: `Please say so if you have concerns.
John Kirkwood: Can you remove "underlying" that is confusing term.
dan_bjorge: Do not need to wordsmith here, but I will try to come up with another word or phrasing.
mbgower: The normative text includes "underlying" so might be difficult to change.
kirkwood: Could be "specified" which is more understandable.
gpellegrino: Tension between what is easy for author but harder for tester....
<david-cox> fair point from Giacomo. layered elements with alpha channels.
gpellegrino: images with gradients particularly tricky.
Wilco: If AG members have concerns, can TF merge regardless?
Wilco: This came up with detlev concern for example.
dan_bjorge: Detlev joined call, so were able to got through...
… for this example we do need AG feedback...
… AG has agreed on ACT rule with pixel picking if color does not match CSS value.
AG has agreed to contradictory things.
<Zakim> alastairc, you wanted to comment on gradients (tangent!)
dan_bjorge: AG also approve using CSS values as acceptable testing method.
alastairc: To giacomo-petri please see understand document which includes gradient examples.
<GN015> A tester might have a high-end graphic monitor with a high resolution, and end user might have an older monitor with lower resolution. The pixels might have other colors with the end user. This is not only uncontrollable, but unforeseeable.
alastairc: WRT resolution on disagreements, that process is exactly what we are trying to iron out.
<TheoHale> We need to figure out a way of transforming an image to reduce the contrast and validate that these images are compliant. Pixel picking will result in bugs being filed that might not help people with disabilities as teams will focus on these issues.
mbgower: We will continue to work on these on github and on friday call and tuesday calls, and refine process
<Wilco> works for me Chuck
chuck: We agree that there is work to do with hashing out process. All agree there is not perfect agree ment.
giacomo-petri: My point about gradients, is that it as a tester with gradiant, instructions provided do not give enough clarity with background collors...
… anti aliasing introduce a variable that test cannot control
Wilco: My question to AG is if color picker instruction is valid?
mbgower: Color picker with text and background is much more reliable and repeatable, does not conflict with using CSS values...
… can ignore anti-aliasing effect by pixel picking from center and using color pick to identifiy repsentiative pixel.
<Wilco> +1 I think so. CSS colors works very well 99% of the time
<Zakim> alastairc, you wanted to say that's the way it has been for colour-contrast checking for many years.
mbgower: with gradient can be tricky, but solid colors are reliable to use color picky. So not necessar a contradiction.
alastairc: It can be a little subjective, but for my testing I like firefox pluging which can flag low contrast reliably and programatically...
… then I can drill down to more subjective elements on a page.
dan_bjorge: Using CSS values uses most of time, but is not rare for discrepancy. Please see thread and examples from JAWS-test...
… even 16 px letters can be an issue.
<GN015> sometimes you have to go through hell
<david-cox> adjourned!
<ShawnT> +1
<laura> bye
<graham> see you all
<rscano> bye