Meeting minutes
<Sam> prestent+
App dev update - version collection
Jon: how done is app?
mk: lots more dev to do
jon: some basic issues need work
mk: raise issues in aria-at-app repo
rich: Expecting version collection in sandbox in May 31
Also fixing errors on Safari
Rich will notifiy CG members when ready for review in sandbox.
Will ideally make announcement on June 2.
Next week agenda will include high-level design discussion for AT dev user journies.
Interpretation of NVDA link announcements
James: about link test plan
one test is for reading link.
screen reader announces name, link role, name, ...
NVDA also addes the word "linked" at the end.
Called out as excess verbosity by one tester.
Matt: any idea what rationale is?
James: not sure, NVDA internally represents this as a state
James: noting that links in UIA haverole of system text and state of linked
Matt: Matt tendancy to regard this as a bug
Michael: +1
matt: screen readers should have to justify excess verbosity.
james: if bug, how should mark this as a bug
How do we track the reason for checking the excess verbosity box?
No link between test result and reported issue.
Matt: we have a data collection problem.
James: we could change the other edit box to be "explaination" and make available regardless of which reason is checked.
Seth: reports page shows one view of results because thy all match. so how do we populate the one reason in report page?
James: How do we determine in a report what to show if someone checks the "other box" and provides an explaination.
Seth: how do we turn 3 reasons into one for the report?
Matt: James can you taking on creating two issues: 1) changing label on unexpected behavior edit box to explanation and making it available regardless of which unexpected behavior is checked 2) Giving admin way of synthesizing expalanations
James: yes
When should testers file issues for conflicts?
James: Joe is proactively filing conflicts as issues.
It is nto obvious when a tester is responsible for doing this?
Seems like this workflow needs to be clarified.
Perhaps the admin should file the conflcit issues.
Matt: Originally we imagined testers resolving some issues without an admin
James: now that we have dedicated test admin support, it may work better if th test admin assumes responsibility for raising issues related to conflicts.
Matt: No problem there, let's just not bake that into the app UI; keep the app flexible.
James: +1. Will handle via communication with testers.
<Matt_King> s/mk\:/Matt\:/