- From: Detlev Fischer <detlev.fischer@testkreis.de>
- Date: Fri, 16 Apr 2021 16:14:02 +0200
- To: public-mobile-a11y-tf@w3.org
- Message-ID: <aaf1edbe-15b1-c640-dbf4-e91c78ec12b0@testkreis.de>
Hi Jake, That's helpful, thanks - hadn't come across this one. Detlev Am 16.04.2021 um 07:53 schrieb jake abma: > > you all know this one? > > https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit#heading=h.9ez6mism9f8d > <https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit#heading=h.9ez6mism9f8d> > > Op do 15 apr. 2021 om 18:13 schreef Kim Patch <kim@redstartsystems.com > <mailto:kim@redstartsystems.com>>: > > *MATF Minutes April 15, 2021 > * > *Link*: *https://www.w3.org/2021/04/15-matf-minutes.html > <https://www.w3.org/2021/04/15-matf-minutes.html>** > > Full text of minutes: > * > > > 15 April 2021 > > > Attendees > > Present > Detlev, Jake, Kim_patch > Regrets > - > Chair > Kimberly_Patch > Scribe > Kim_patch > > > Contents > > > Meeting minutes > > https://docs.google.com/spreadsheets/d/1bsze5rAu-6tkWBTGyrcm4tdsGvZAaEBBUCDsQZngl2k/edit#gid=39173941 > <https://docs.google.com/spreadsheets/d/1bsze5rAu-6tkWBTGyrcm4tdsGvZAaEBBUCDsQZngl2k/edit#gid=39173941> > > Detlev: test one thing – a button and you could take the different > aspects of that. They also translate to user needs. > > 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 > > 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. > > 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 > > Jake: user needs are like the better version of the benefits we > have right now > > 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 > > 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 > > 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 > > 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. > > Jake: it is a mix of stuff you see with technical even if the > person never sees What's on the screen > > 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 > > Kim: so they are the same > > 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 > > Jake: checklist for those user needs you see the more practical > explanation for each – this is just the first draft > > Detlev: is there clarity for you about the scope of future > guidelines after this exercise – Will there be more, will there be > less. > > Jake: that's a very good question – first you need to collect all > the ingredients Before trying to structure them > > Detlev: that's exactly my point > > Jake: collecting user needs, functional needs, relate to outcomes. > Then guidelines created > > Kim: look at all user needs at once > > 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 > > 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… > > 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. > > Kim: any more lessons learned from the exercise > > Detlev: Looking at outcomes – Looking at granularity useful here to > > Jake: motion actuation outcome – One of outcomes might be > applicable to other criteria > > Kim: top one – several different types of outcome wordings – last > one is broader rather than more Granular > > Jake: doesn't work to mix – Just more than one outcome > > Detlev: outcomes on the atomic level? > > Jake: outcome is like a goal > > Jake: they look pretty much like success criteria > > Detlev: 1.1.1 pretty wide > > 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 > > Jake: I think the different groups have taken slightly different > approach > > Jake: there is a definition – outcomes are written as testable > criteria that include information how to score the outcome > > Detlev: they can be several tests that's my point – several atomic > tests > > Detlev: trying to collect the things that we put on the table that > would be the right aggregations > > 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 > > 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 > > Detlev: concerned that if we convert several SCs, there might be > overlap – need to look at them as a whole > > 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 > > * > * **___________________________________________________________ > > Kimberly Patch > (617) 325-3966 > kim@scriven.com <mailto:kim@scriven.com> > > www.redstartsystems.com <http://www.redstartsystems.com> > - making speech fly > > PatchonTech.com <http://www.linkedin.com/in/kimpatch> > @PatchonTech > www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch> > ___________________________________________________ > -- Detlev Fischer DIAS GmbH (Testkreis is now part of DIAS GmbH) Mobil +49 (0)157 57 57 57 45 http://www.dias.de Beratung, Tests und Schulungen für barrierefreie Websites
Received on Friday, 16 April 2021 14:14:19 UTC