Meeting minutes
AT Version Collection Experience
MK: Two things to talk about
MK: We are expected to start building the experience in the next spirit on March 21st
MK: Rich?
RN: One issue is having a good design by the 17th
MK: This is a blocking feature for getting SR companies on board, ASYNC review
ST: Isaac has been working on a design based on discussions in this group, there are some edge cases that need to be worked out
ST: There are a few issues we could discuss here
MK: Issues would be availabel early next week
ST: That is the plan
MK: We might not have a qourm next week
ST: Hopefully get to a good place next week
MK: We will encourage participation next week
MK: Open issues we can discuss?
ST: Publishing the results on the ARIA AT reports page
ST: We need to be on the same on browser versions
ST: We don't want an Admin manual updating the list, and there are issues with people using a difference browser to input content
MK: The second requirement, we should not use as a blocking issue, we can get it out there with other this issue
ST: I don't think it will save us much time now
ST: The admins browser making edits it could be different of the test, so automating getting it has some issues
MK: We talked about have a prompt
ST: In the current prompt would be leave the current value or switch to what I am doing now
ST: So if we want to show a drop down, we could get an API on browser versions, maybe we care only about major versions
MK: There maybe near and long term questions about the detail of the version
MK: From a screen reader perspective will probably not need as much detail, where as browser developers will want more information
ST: We cannot open up the field to random edits
MK: We do not want manual editing at all
MK: If the other option is recording ..
ST: The user does not do anything about the browser and AT because that is part of the test
ST: We have two ways of showing how may test pass, there are more than on person running a test and some people might change their browser version half way through a test
MK: I have been thinking about these things, go to the ARIA-AT page ...
MK: I am going to disclose menu, so I see from JAWS latest ..., choosing "complete results
MK: There are headings for ever single test
MK: These results are the same for every tester
MK: For every one of these 30 test, we have like a run history collapasable section, with submission date information with browser and screen reader
MK: We would have a place to see each test, when and who ran it, so a history of the page
ST: Our goal is make the summary page as simple as possible
ST: I agree knowing where the data comes from is useful, but the bigger issue is how to look the dependencies right now and in future test
MK: You could make the run history to show prior tests
ST: We can punt on it right now, but this is an important longer term issues on looking at time history, let's look at it sooner rather than later
MK: When we are working with SR companies they will want information in a certain way
ST: Already we are using latest for the reports, we are not losing data, a report might not include from same screen reader
MK: SR developers want to make sure the data is from the most recent version, they care about recency
ST: It will be complicated with auto results, we will need some charts
MK: We are mostly focusing getting screen reader companies in action
ST: What do you need for reviewing the design, is it screen design or work flow, we need this for Issac to be able to provide the information needed
ST: There is a very verbose way to do this, .....
MK: That is good
MK: We will have 3-4 people who cannot see the wireframes
MK: Triaging remaining agenda items
Updates
MK: The sandbox will be changing through Tuesday next week, we need feedback by next Thursday
RN: Just put the changes in =, no review from MK
MK: I will look at the sandbox after the changes
RN: We are tracking for the 16th, and we can send out a message
MK: We might be able to deploy it quickly
SS: I day for review is pretty short, we should have at least 2-4 days
MK: Let's keep in mind that MK and JS are the primary people
RN: I did see a merge I will check on timing
When can report data be deleted?
MK: 637, how big of an issue is it
ST: It is pretty important, the issue is still relevant
MK: Let's not discuss 637 right now
Issue 638
<Matt_King> issue 638: https://
MK: This is related to opening a select only combobox
MK: In a standard HTML select, NVDA announces it as a combobox, may not hear size and position information
MK: A standard SELECT doesn't have a separate list
JH: I said it failed since it did not say combobox
MF: List is close
JH: There is a difference between a list and comobox
MK: There is a technical difference
JH: If list is acceptable, then I can change my result
MK: This kind of flexibility, it conveys the concept of combobox, JAWS may say listbox and then NVDA says list, that is confusing
JH: I pose a question, is list fine?
MF: I am fine for this one, since it is consistent within NVDA for other similar situation
MF: But is this good in general for SR to usefdifferent terms for the same content
MK: If we feel like it could lead to user confusion
MK: ARIA has a 140 semantics
MK: They should not have to distinguish between all them, so SR are trying to simplified, since the announcements are describing the visual ..
JG: Developers also have expectations on what should be spoken
MK: We should be telling developers when things are good
JH: The consensus is that list is fine
MK: NVDA is being consistent with its self too
MK: This is going to happen alot, how does the issue title explain the issue
MK: I wonder if we need a record or a table of equivalence so people can see these issues
Discussion of why edited test are still failing
Discussion of the "selected" assertion in single select lists
MK: We need to make sure they can find out the state
rrasgent, make minutes