<michael_fairchild> Sorry, I have to step away for just a second.

PLAN FOR TODAY'S MEETING

1. Web developer use cases

2.

2. Screen reader developer use cases

3. ARIA-AT contributors use cases

Web Developer Use Cases

<Jean-Francois_Hector> Recap of the output of last week's conversation. We're going to go through this in a minute https://docs.google.com/document/d/1c81otH0MP79qGPjOFH06LCKT_4STaqNNExAd9OmvcWs/edit#

jf: summary of last week's discussion

<Jean-Francois_Hector> Recap of the methodology for identifying use cases: https://docs.google.com/document/d/1HteU9qUBNVfCr2EI5u9oWInEB15jNQb-Kmr8yFQvdC4/edit#heading=h.4d5j1o4nkzd

and second doc is recap of methodology

Summary of objectives and how we will achieve them.

Identify use cases for people using the tool.

Traditionally use cases may mention a feature or task. We will not assume a type of solution. we define in terms of a real situation or struggle.

Then, once we define the situation or struggle, we can then design solution. Today is not about designing solutions.

Caviot: These are the situations we can imagine. We may have some gaps in knowledge. For instance, none of our screen reader developers. Down the road we may need to loop them in.

Summary of last week doc includes lists of key user groups. Then, we have some struggles for web devs, then a section for AT devs.

Things marked draft are JF's summaries or analysis, not directly from meeting discussion.

JF going to read out doc, then we will discuss what is missing.

Seth: People using AT, e.g., PwD.
... they may have some use cases.

JF: Obviously there could be audience overlap, AT dev could also be AT user, web dev could be AT user.
... reads off list of user groups.

<Jean-Francois_Hector> Recap of the output of last week's conversation. We're going to go through this in a minute https://docs.google.com/document/d/1c81otH0MP79qGPjOFH06LCKT_4STaqNNExAd9OmvcWs/edit#

<Jean-Francois_Hector> Recap of the methodology for identifying use cases: https://docs.google.com/document/d/1HteU9qUBNVfCr2EI5u9oWInEB15jNQb-Kmr8yFQvdC4/edit#heading=h.4d5j1o4nkzd

JF: asks about QA testers ... are they an audience.

Group discussion: Yes, they prob have same types of questions as web devs though.

MF: List looks good.

jf: will have 1:many relationship from use cases to audiences.

Now, web dev use cases ...

Goal is to come up with most typical, most common, not necessarily to be complete.

First case: As web dev, I am not clear what aria attribs are supported, so my job is complicated. I don't know what is coded right or wrong based on how AT behaves.

scribe: possible outcomes: I want my UI to work for as many people as possible, and I want to get the piece of UI built ASAP
... Later, if someone reports a problem, I know if the problem is with my code or in another place in the stack.
... I want to feel more and more confident rather than discouraged. Instead of thinking ARIA is harder and harder, I feel like I know what I am doing.

mk: What about outcomes that would be good, something user is hoping for, but solution is outside scope of project.

jf: we want to include those.

mk: Hopeful outcome for wev: Where there is a support gap, I know how to work around it.

Another web dev use case: I just wrote some code, I tried to make it accessible, and AT is not behaving as I expected. Where is the problem? I don't know how to continue?

outcomes: similar points to before.

mf: Another outcome: I understand what the expectation for the screen reader is.

jf: Sometimes the sr is doing everything right, but my understanding of what it should do is wrong and dev learns what the actual expectation should be.

Screen Reader Dev Use Cases

jf: Tried to take discussion from last week and shaped it into situation/struggle format.
... these could be far off.
... Could you name a few typical situations?

mk: One situation is sr gets a bug report about incompalitibity with a site. SR dev need to know whether it is sr problem or site problem.

mf: SR dev may not know what "support" means for a specific attrib.

Discussion of effects of lack of broad agreement of aria expectations in the sr community.

jf: What will help us is what situational struggle is experienced by sr devs.

Discussio of inviting an SR dev to help us understand their struggles.

Future meetings and next steps

No meeting on May 1 due to ARIA WG F2F all-day meetings Tues, Wed, Thurs next week.

Next meeting on May 8.

Will continue with use cases for contributors to ARIA-AT project, e.g., people doing AT assessments and managing the results.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: Matt-King michael_fairchild Jean-Francois_Hector shimizuyohta
No ScribeNick specified.  Guessing ScribeNick: mck
Inferring Scribes: mck

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)