Meeting minutes
<Karla> > present+
Whoop
Guidance proposal
JJ: Not much progress. Jamie made some suggestions: Making issues for all SC so that we don't create them after the meeting
+1
<Illai> +1
quinitnb: allows for async working and contribution on the issues
wow misspelled my own name there
JJ: Will start grouping the discussions so that it's in one place
+1
Jamie: Maybe have some folks take separate ownership of issues - assigning specific people to an issue to take charge of first draft content. Gathering relevant data etc
<Tori> Big +1 to what Jamie is saying. It would help me contribute if I could focus (and focus on what I'm most knowledgeable about too).
<audrey> +1
Jamie: This would allow groups to meet beyond the one meeting
<Karla> +1
<Illai> +1
JJ: Would like a co-facilitator to help with all the management of this
<Tori> I can help with facilitating
JJ: Mostly about organising the meetings
<Tori> I can never scribe because of my AT, but facilitation is definitely something I can do now that I'm more available.
No worries Tori
Jamie: Should we be making action items for each of the SC's
JJ: There are many ways (like Github's tools) that we make for speeding up everything and be less reliant on this meeting
<Jamie4> I was kicked off
1.4.1 Use of Color - Level A
Could also be VPN's
JJ: How might apps be different? Best practice?
Aashutosh: Talking about the use of textures
Tori: We may want to be careful around visualisation - the colorblind folks hated textures. We should veer away from being too prescriptive, and allow many mechanisms for visualisation and communication
Also Android has 0 libraries for data-vis - it's all bespoke at the moment
SongBird Charts was good back in the day, but it's old now
<Tori> HighCharts is the lead in data viz now
The car has no wheels!
<Tori> No clue about their mobile capabilities
Thanks Tori, will check them out
Detlev: We want to allow people to have many mechanisms for solving this problem
+1
<Jamie> +1 to Tori, not adding specifications outside of WCAG text for this round of MATF documentation
1.4.2 Audio Control - Level A
Independent from system volume? Super weird
<Mick> I would say we should follow the current WCAG structure - otherwise we could rewrite a lot of the success criteria.
JJ; There is some overlap, but this is under perceivable and focused specifically on audio, as opposed to operable and more general
+1 Mick
<Jamie> +1 to Mick
JJ: What about Splash screens?
<Tori> I see (hear) it on spa and salon websites a lot still in the US
<Tori> Chromium and other browsers have the ability to mute now, but that would fall under UAAG IMO
Jamie: Do we need to discuss this, what do we need to change
Tori: Building on what Jamie said - a lot of these are general - these are the areas that are fairly agnostic
<Jamie> +1 to Tori,, and we need an actionable item from Agendum 2
JJ agrees
I do feel that since phones have a dedicated rocker for volume that it should respect the user settings
Jamie: Can we add action items for agenda 1 + 2 to take ownership for 1.4.1 and 1.4.2?
ACTION: Create subgroup to discuss 1.4.1 and 1.4.2 within the Github repo
<JJ> move to previous agendum
1.4.3 Contrast (Minimum) - Level AA
JJ: Raises the point about large text measurements
<Jamie> +1 to Illai
<Illai> Thank you. I missed it
+1 to Illai comment on sizing - I like what the Evinced MCAG guidelines did in reducing to a standard measurement
It would be nice if we knew what minimum text size is...
<Mick> Regarding the large text - with screen glare and viewport size i think there's an argument to require all text to meet 4.5:1 contrast. Also lot of time testers won't have access to native code in my experience when testing and as a result there's an inability to accurately determine the font size of text in native applications.
JJ digs to the notes - perhaps we can make this more discoverable?
JJ points out SP for android text
<Jamie> +1 to mick and quintinb
<Jamie> re minimum text size
<Detlev> For what it's worth, I have tried to formulate a way of assessing whether text falls under "large text" based on screenshots and measurements of font height (it's in German so you would have to get this translated by your browser)
There are places where a reference to some kind of tool would be useful (e.g. input SP size)
<Jamie> Detlev can you summarize in a sentence?
<Aashutosh> +1 to Mick
<Tori> +1 to what JJ is saying about real color vs. coded color and size of text
<Detlev> You take a screenshot, load into something like Photoshop take into account the physical to CSS pixel ratio, measure text height...
JJ: 2 issues - 1. When no source access - testing is difficult 2. Determine the font size (also source problem)
<Detlev> @Jamie does that help?
<Detlev> APCA is not current WCAG guidance...
Aashutosh: Since WCAG is rated for desktops and phones live in the wild, should we not reconsider contrast. There are also different mechanisms for measuring contrast, should we use things like APCA (I might have missed this)
JJ: APCA is not relevant for 2.2 at the moment, but it has utility
<Aashutosh> quintinb the question was two parts. 1. should the contrast ratio be stricter for the apps, since the mobiles can be taken outdoors in brighter sunlight and under direct glare. 2nd. should we use APCA over traditional contrast
Jamie: Should we have SC specifically for conditions where source access is not possible
ACTION: How to deal with source code access vs no-source code access when testing
Thanks Aashutosh - trying to keep up and actually listen!
I had a bad suggestion lol
JJ: Can we expect testers to have access to tools - there are many hurdles to that (e.g. platform / cost)
I agree with Aashutosh to be honest - impact could be fairly big
<Mick> Regarding requirements around access to source code or not - I think it's so important the mapping we provide for native mobile are testable given how they are pointed to by legislation. And i think a lot of testers unfortunately just don't have access to code and would be my recommendation on how we measure what is testable.
<Jamie> +1 to mick
+1 Mick - text should be a "reasonable" size - but what that means I don't know
<Jamie> +1 to emphasize what is testable
JJ: Suggest 1.4.5 to the next meeting
+1
JJ: Are there any other issues we should talk about with our time left?
1.4.5 Images of Text - Level AA
<Jamie> quiet group
Closing
Detlev: When we pick up contrast - there are some native elements that don't meet requirements - probably best for 1.4.11
JJ: EN301549 has an issue - note on Github
2.4.2
<Jamie> proposal: quintinb as first volunteer for 1.4.1 Audio Control Github issue
<Mick> Apologies I'm in noisy environment and can't speak up but regarding sub groups - I think it's a good idea to break out the success criteria that are least likely to have any variations and get a group vote on them before a sub-group takes over, would be a good first step.
<JJ> w3c/
<Jamie> (get the ball rolling...?) and Aashutosh first volunteer for 1.4.3 contrast
<Jamie> and Mick as well ?
<Aashutosh> Jamie yes. I dont know how to officially test this, but I am excited
<Mick> sure
<Jamie> quintinb I'd think up to the subgroup members based on timing and AT needs
I don't mind - just need some details about how to facilitate the groups and meetings within there - also gathering the kittens who are interested in chatting about it