IRC log of matf on 2021-04-15

Timestamps are in UTC.

15:04:47 [RRSAgent]
RRSAgent has joined #matf
15:04:47 [RRSAgent]
logging to https://www.w3.org/2021/04/15-matf-irc
15:04:49 [trackbot]
RRSAgent, make logs public
15:04:49 [Zakim]
Zakim has joined #matf
15:04:51 [trackbot]
Meeting: Mobile Accessibility Task Force Teleconference
15:04:51 [trackbot]
Date: 15 April 2021
15:05:02 [Kim_patch]
https://docs.google.com/spreadsheets/d/1bsze5rAu-6tkWBTGyrcm4tdsGvZAaEBBUCDsQZngl2k/edit#gid=39173941
15:05:18 [Kim_patch]
present+
15:08:14 [Kim_patch]
Detlev: test one thing – a button and you could take the different aspects of that. They also translate to user needs.
15:08:50 [Kim_patch]
Detlev: focus, different users. Doesn't matter whether helps blind users or keyboard users – important to spread them all out then try to rearrange and group them in a way that makes sense
15:10:02 [Kim_patch]
Detlev: the guidelines for implementors and authors to do the right thing. Of course it's good if they know user needs, but we need to convey technical requirements. We can use the user needs to get all those things that need to be pinned down and tested. But for the arrangement and meaningful clusters in technical terms user needs may not be that necessary in my view.
15:10:24 [Kim_patch]
Jake: user needs were never used also not in silver for testing material. One of the things we would like to show what is the user need what is the functional need and create functional outcome
15:10:58 [Kim_patch]
Jake: user needs are like the better version of the benefits we have right now
15:11:42 [Kim_patch]
Jake: User need can be very specific very granular and we might have billions of them in the world – a good way to explain to someone faster the reason the criteria exists
15:12:04 [Kim_patch]
Jake: what I thought was interesting was I was looking for the boundaries of user needs – user need to operate okay but it can be a lot of new user needs behind it
15:12:28 [Kim_patch]
Jake: thinking about a criteria when is a user need small enough that it's like a short as possible but enough to service a clear – technical user need for a criteria
15:13:05 [Kim_patch]
Jake: user needs to operate controls by label name Just a very interesting exercise for labeling name. What is the user Need – I was struggling.
15:13:42 [Kim_patch]
Jake: it is a mix of stuff you see with technical even if the person never sees What's on the screen
15:18:21 [Kim_patch]
Kim: Label in name users – speech, anybody who needs to look at programmatic name – programmers, also blind users working with anyone who is looking at the label on the screen
15:18:26 [Kim_patch]
Kim: so they are the same
15:18:52 [Kim_patch]
Jake: functional needs are not the same as user needs but they both serve to create the master user needless that you can use for a horizontal review
15:19:20 [Kim_patch]
Jake: checklist for those user needs you see the more practical explanation for each – this is just the first draft
15:20:50 [Kim_patch]
Detlev: is there clarity for you about the scope of future guidelines after this exercise – Will there be more, will there be less.
15:21:18 [Kim_patch]
Jake: that's a very good question – first you need to collect all the ingredients Before trying to structure them
15:21:23 [Kim_patch]
Detlev: that's exactly my point
15:21:41 [Kim_patch]
Jake: collecting user needs, functional needs, relate to outcomes. Then guidelines created
15:23:00 [Kim_patch]
Kim: look at all user needs at once
15:23:50 [Kim_patch]
Detlev: my concern is guideline normative outcomes connected by an and, and if you meet all of them the guideline gets a pass, and also not black-and-white pass but some measure
15:25:07 [Kim_patch]
Detlev: Sometimes all these things are all lumped together. That means in practice that in nearly all tests we do there is the failure of 1.3.1 – Almost always end up with a fail because an umbrella kitchen sink test criteria. Same thing seems to be happening with structured content in my view. There are so many things going into that visual aspects, cognitive aspects…
15:25:37 [Kim_patch]
Jake: I've done two or three months of experimenting with all the headings different outcomes, files I saw more issues to be solved then solutions right away.
15:27:15 [Kim_patch]
Kim: any more lessons learned from the exercise
15:31:04 [Kim_patch]
Detlev: Looking at outcomes – Looking at granularity useful here to
15:31:27 [Kim_patch]
Jake: motion actuation outcome – One of outcomes might be applicable to other criteria
15:38:28 [Kim_patch]
Kim: top one – several different types of outcome wordings – last one is broader rather than more Granular
15:39:14 [Kim_patch]
Jake: doesn't work to mix – Just more than one outcome
15:39:35 [Kim_patch]
Detlev: outcomes on the atomic level?
15:39:47 [Kim_patch]
Jake: outcome is like a goal
15:39:58 [Kim_patch]
Jake: they look pretty much like success criteria
15:40:12 [Kim_patch]
Detlev: 1.1.1 pretty wide
15:41:02 [Kim_patch]
Detlev: I'm still getting at the right level of outcome – if you say it's linked to some functional need that it would be something like an image control has a programmatically accessible descriptive Name. That would already combine the alt Attribute and Descriptive name. I'm still getting at the right level
15:41:10 [Kim_patch]
Jake: I think the different groups have taken slightly different approach
15:41:31 [Kim_patch]
Jake: there is a definition – outcomes are written as testable criteria that include information how to score the outcome
15:41:42 [Kim_patch]
Detlev: they can be several tests that's my point – several atomic tests
15:42:29 [Kim_patch]
Detlev: trying to collect the things that we put on the table that would be the right aggregations
15:52:40 [Kim_patch]
Detlev: when we go through Success criteria – not clear why things are grouped the way they are now. Technical the same – meaningful link and accessible names, Button, image, name – it's all about accessible names should adjust not be one guideline? Things like that are obvious
15:53:37 [Kim_patch]
Detlev: basic decisions about grouping can only be made with everything on the table and a fair amount of iterative moving around – should be separate for example programmatic Description from the visual Aspects? Good reasons for together or separately. I think these things need the wide scope and a good collection of functional outcomes – the bits we want to sort
16:01:34 [Kim_patch]
Detlev: concerned that if we convert several SCs, there might be overlap – need to look at them as a whole
16:02:12 [Kim_patch]
Kim: we can do some of that just with the mobile SCs – see where there is overlap and maybe see where there's overlap and note outside the mobile SCs
16:02:41 [Kim_patch]
zakim, list participants
16:02:41 [Zakim]
As of this point the attendees have been Kim_patch
16:02:56 [Kim_patch]
present+ Detlev, Jake
16:03:00 [Kim_patch]
zakim, list participants
16:03:01 [Zakim]
As of this point the attendees have been Kim_patch, Detlev, Jake
16:06:29 [Kim_patch]
rrsagent, make minutes
16:06:29 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/04/15-matf-minutes.html Kim_patch
16:10:47 [Kim_patch]
chair: Kimberly_Patch
16:10:54 [Kim_patch]
rrsagent, make minutes
16:10:54 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/04/15-matf-minutes.html Kim_patch
16:13:05 [Kim_patch]
rrsagent, bye
16:13:05 [RRSAgent]
I see no action items