Meeting minutes
App updates: New candidate test page and new Test Management page
<Matt_King> Seth: We've been collecting feedback on new candidate test page.
<s3ththompson> https://
<Matt_King> We have been working on some of the feedback.
<Matt_King> We have changes to markup structure.
<Matt_King> Working on updates to copy.
<Matt_King> Implemented most of that feedback.
<Matt_King> Also working on test management page is in review and is in sandbox.
<Matt_King> Would like to discuss some of the copy.
<Matt_King> Once we have ability to publish test plans as recommended, we need to be able to distinguish candidate from recommended in reports.
<Matt_King> Question about splitting data into multiple columns.
<Matt_King> Just want to confirm that it is preferable to navigate between columns when reading that information.
<Matt_King> Matt: Overloading individual cells is only helpful in certain situations where it is important to be able to distinguish rows from one another
<Matt_King> James: putting data into separate cells is important where you need to compare rows.
<Matt_King> James: giving some specific examples of when it is difficult to compare rows when too much data is in one cell
<Matt_King> Seth: Would like to talk about copy for distinguishing candidate from recommended test in reports.
<Matt_King> Currentlly we have "Unapproved report" and a disclosure for candidate test results.
<Matt_King> Matt: we could make a disclosure for recommended reports that mirrors the current language by calling recomended test results as "Approved Reports"
<Matt_King> Seth: Should I open an issue to workshop the precise copy?
<Matt_King> Matt: yes
<Matt_King> Seth: Plan to deploy on Tues afternoon or Wed morning next week.
<Matt_King> James: Seemed like vendors could see buttons for changing target date
<Matt_King> Seth: The app might have been seeing you, James, as an admin even though you were testing as vendor.
<Matt_King> James: Had difficult time getting the finish button to appear when on last test
<Matt_King> Pressing it didn't open finish dialog.
<Matt_King> James: We pressed not approved in the finish dialog, and the main page didn't update
<Matt_King> Seth: Idea is that it is in review until not approved
<Matt_King> Matt: What about showing view progress in the table
<Matt_King> James: Maybe use copy like reviewed, not approved yet
<Matt_King> Seth: will consider that
Update on feedback from screen reader vendors and consequent test changes
This morning Matt, James, and Sam met with Vispero to review updates to candidate test experience, discussed our plans for sharing data in apg, then discussed the three items of feedback they raised.
Vispero was happy to see the new candidate review experience
Vispero appreciated our approach of a process to not publish the data in the APG until the vendor has had a chance to review
We still need to share the updates to the candidate review experience with Apple
James: We discussed the following items of feedback. The alert role will not be specifically announced, JAWS will only announce the text. We discussed this in our CG meeting a few weeks ago and decided to downgrade this to optional
James: Vispero was happy to follow this solution. We will update the test soon
James: When a user is focused on an item in a menu, when they press up arrow to query their position, in our test we have an assertion that the screen reader must assert the position in the menu
James: Vispero agreed to consider providing this info in a menu. No changes required to our test
Matt: This fix will not make it into the December update
James: Tabing into a radio group. We asserted that when you move out of a radio group, that the Screen reader needs to say the name and the option. Vispero said when tabbing out of the list you don't need to hear the name and option again
James: Matt and I agreed that this isn't desirable behavior, so we agreed to remove the assertion from the test
Matt: This is exactly the kinds of things we want ARIA AT to do!
James: Yes it was a very productive call
JoeHumbert: How does this change the base output for JAWS vs VO? The changes that we agreed to make, will there be a difference in the base information different screen readers say? Like for alert, will different screen readers have different output?
James: Yes
There will be more consistency in what is conveyed, but it may sound different
Matt: With Vispero, we are closing many gaps! Vispero has agreed to make every single change we suggested expect for the ones we discussed today
Matt: Vispero would like to review almost every assertion we make
James: When vispero has encountered a failing assertions in a test, they have already turned all of those issues into bugs in there development system and they are working on implementing many of them in the next release of JAWS
Switch test conflicts (Issue 814)
<Matt_King> https://
James: We also discussed this a few weeks ago in this meeting. We have a test plan that targets the switch design. It uses the aria checked attribute to indicate if its on or off
James: That caused some consternation even before we were a project
Previously the Switch was mapped to toggle button role in i accessable 2
Within the mapping of the states, it was mapped as checked and not checked
James: In essence, the SR is being told it is toggle button checked or not checked
James: For NVDA, they told us they made the decision to remap the role to checkbox
James: They could have changed the state instead, so that it was pressed or not pressed
James: Originally, there was some concern that users wouldn't know what a switch was, or how to operate it
James: Now its feasible to think that some users will hear checked or not checked, and know the switch is turned off. Its also feasible that another user would hear checked and not understand if it was on or off
James: We now have a situation, where we have a role that is being presented that we think is incorrect.
James: Should the test fail? or Pass?
James: in our tests, we noticed we had a lack of consensus and understanding
Matt: It is in iA2 the case that there is an expectation for the XML role property to be utilized, because we knew ia2 had limitations and getting changes to ia2 was very difficult.
Matt: One question I have is, whether or not, NVDA is using the XML role property ever? If so, why not here?
James: Technically they are using it here, just not for the purpose you want
James: Want you want is using it in a user facing way\
James: I should note for completeness, depending on which API the screenreader is using the output does change. i.e UIA
Matt: Theres a part in me that wants to say its a switch and should be conveyed as such
JoeHumbert: I agree, I don't think it can be argued that switch is an unknown concept know
James: I'm less opinionated on that, I think there was some consensus that they would be better off if they called it a toggle button. Check box is the worst of all worlds
Matt: I think role semantics should take precedence over state semantics
Matt: Not conveying roles should fail.
Matt: We could note that toggle button and switch are equivalent.
James: Are we okay changing the test so that they align with failure?
Matt: yes
James: I will write all of this up