Meeting minutes
<jesdaigle> +present
Multiple Meeting Logistics
<Matt_King> Will have combined minutes page, but two separate wiki pages for agenda
<Matt_King> Seth: what about email announcements
<Matt_King> JS: votes for 2 separate emails
App Development - Logistics
<Matt_King> Seth: this will be a bi-weekly CG subgroup meeting
<Matt_King> We have a GitHub project on the aria-at-app repro. Structured as canban board
<Matt_King> Currently not very populated.
<Matt_King> Each sprint issues will be on the board. The issues will be in aria-at-app repo.
<Matt_King> mk: asked about having roadmap doc on wiki
<Matt_King> Seth: talk with team about what that should look like
<Matt_King> We are in a state of flux b/c doing research and roadmap is not quite settled.
<Matt_King> Process isn't yet as linear as we would like; will be about a week before we have enough info to decide on the overall roadmap.
<Matt_King> Side note: plan to follow similar processes and practices for other workstreams.
<Matt_King> Two weeks from today Bocoup has all hands so will not have meeting on april 15
<Matt_King> mk: let's figure out when to have replacemeeting. How about have next meeting on april 22 and then bi-weekly after that?
<Matt_King> Marie: that should work
<Matt_King> Conclusion: Next app dev meeting on April 22, then bi-weekly after that
App Development - Previous Sprint Update
Previous sprint update
<Matt_King> Working on upgfront research
<Matt_King> Seth: first looking at unifying test authroing format to support automated tests
<Matt_King> Alex posted issue 404
<s3ththompson> Hybrid Test Format https://
<Matt_King> James commented that we probably need a presentation/discussion to fully understand.
<Matt_King> Plan to discuss during april 8 cg call and then potentially schedule f/o deep dive with stakeholders.
<Matt_King> This plan gives a lot of latitude for how it is implemented; not all features are needed now. it is future looking.
<Matt_King> there are many paths to get there.
<Matt_King> Co-design with James and Sina expected.
<Matt_King> James: I think it needs to take more input by studying current tests.
<Matt_King> Need to be able to accept different wordings for similar assertions.
<Matt_King> This proposal doesn't have much explanitory prose so difficult to understand the point of each change.
<Matt_King> We hope to learn next week the reasons behind the changes.
<Matt_King> Seth: as we go forward, we will hopefully have better understanding of the kinds of info we each need in order to co-design effectively.
<Matt_King> Alex: do we want updated version of proposal before next meeting?
<Matt_King> Seth: perhaps not but maybe add more info about the design changes
<Matt_King> James: that would be helpful. I can also add some info about what PAC regards as important when writing tests.
<Matt_King> James: as we work through these things, it would be good to write about them as we do them
<Matt_King> Having notes about that rationale would be very helpful.
<Matt_King> Seth: In last sprint, we are also working on is the test rendering API
<Matt_King> Related to need for a button on test review page for raising github issue.
<Matt_King> Right now, the test running and reading experience is very different between the app and hosted version in the github repo.
<Matt_King> Early on, we decided that thtest would just be an html file, which meant that validation is embedded in that html file.
<Matt_King> that code does different things depending on the environment.
<Matt_King> We pass parms into the scripts to control the behavior.
<Matt_King> This is largely ad hoc complexity.
<Matt_King> This allows each file to be opened in simple server and render the form.
<Matt_King> What would be better is if there were a proper events API.
<Matt_King> This would mean a refarctor of harness.js
<Matt_King> We could then render on demand without iframe with anything, even a react wrapper, for instance
<Matt_King> Another reason for this is that embedding a form in an iframe makes managing focus trickier.
<Matt_King> Is that right James?
<Matt_King> James: Two pront problem.
<Matt_King> Sometimes focus was not getting set consistently, which can be caused by iframes.
<Matt_King> Second, if you have frame surrounded by chrome, you hqave to some kind of messaging across the boundary.
<Matt_King> If there is no iframe, all those potential focus management issues go away.
<Matt_King> Seth: having more programatic control over rendering improves our ability to manage focus and overall accessibility.
<Matt_King> James: should also think of security. consider the use of someone embedding the content.
<Matt_King> Losing the iframe means you lose the sandbox nature of it.
<Matt_King> Seth: the html doesn't store any data; sends all to parent.
<Matt_King> Good to think about other places where the tests will be embedded.
<Matt_King> Discussion of considering other use cases for embedding without going beyond scope.
next sprint
<Matt_King> We next carry the working model changes into the app at the data layer.
<Matt_King> And how we could use GraphQL to support that.
<s3ththompson> https://
Community Group Meeting topics follow from here\
Removal of older editable combobox/autocomplete both tests (issue 53)
James: we made the decision to make a new issue/branch/directory because of the process that PAC has adopted for writing tests and how the test format has changed.
James: Matt raised a concern about creating a new test rather than updating the old one.
James: it would be good to work out a path forward to remove those old tests
Matt: I'm comfortable with removing the old one and changing the name of the new one
James: in the repo, there is a JSON file that maps the tests and human readable names. Do you want us to update the issue to remove the word "updated"?
Matt: I'm not sure if we will need to do this again in the future
James: it has happened in the past with other tests
Matt: instead of having "updated" in the test name, I'd rather add something like "deprecated" in the titles of the old tests
Matt: Something like "deprecated as of date"
James: what needs to happen to get rid of the old plan?
James: is it as simple as deleting the directory? Maybe that's a Bocoup questions?
Seth: do you mean what will happen on the app end if that happens?
Matt: yes, and will it cause any artifacts in the system that we don't want?
Seth: we might need to get back to you
Matt: to make it clear: how do we delete a test plan and all associated data?
Matt: a question for the future: what if we had previously published data and we decided that we need to delete a test plan? Would we want to remove data from the site as opposed to keep it?
James: I don't think so, but issue 53 is a special case because nothing has been published yet.
James: but if anything has been published, we should archive them instead
Matt: I agree with that
Seth: the results are tied to the git has from aria-at. So results should still exists. However, an admin would need to pull in the most recent version of the test from GitHub, and the test would disappear. Any time we show or hide new tests, we have to update the version of the entire aria-at repo.
Matt: are you saying that there would be no results on the report page?
Seth: the data is still there.
Sina: step 1: update issue 53 (use the word depricated); step 2: add a question to step 2 about what happens when the directory is deleted; step 3: open an issue in aria-at-app about how do we delete a test plan?
(discussion around using git hashes for versioning)
Seth: let's talk about it for sure. there are a lot of reasons why we are using a git hash that we haven't discussed yet
James: can you write those down in the issue?
Seth: the collection of tests that the app shows should not be managed by the app. That should be managed by a repo somewhere.
Matt: we might need some separate deep dive work to move this foward
Matt: can you raise an issue in the aria-at-app repo for how to delete a test plan?
Seth: yes that makes sense
Test review coordination (issue 410)
Matt: to repeat Michael's advice "nothing is going to get done unless we explicitly ask people to do tasks"
Matt: the activity here is that people who are screen reader testers, will be testing the tests themselves. We are reviewing the tests to determine if they are accurate? Do we have the right commands, instructions, assertions, priorities, etc.
Matt: we really haven't written down what we expect people reviewing tests to examine. James, you did write a page that details how you approach writing tests?
James: not yet
Sina: do we need an onboarding document?
Matt: we might need an onboarding document, to describe the basic mechanics of 'this is how you get to the test queue and run a test'
Alyssa: that would be helpful, and it would be helpful to read the terminology used
Seth: on the home page of the wiki, there is the working mode document. We might want to make that more discoverable.
Matt: it would be good to have a 'getting started for AT testers' page
<s3ththompson> the vocabulary for ARIA-AT is at the top of the working mode doc: https://
Matt: Alyssa, do you have a github account?
Alyssa: no
Matt: that would be a good first step
Matt: can someone on your team own the getting started documentation?
Sina: yes, what's the timeline
Matt: asap, because people wanted to get started now
Sina: can we make an issue in aria-at: 'working issue for how to get started'? And discuss the list of steps to get started.
Sina: We can discuss that offline and once we have that, we can create a page?
Alyssa: once you get that established, then maybe I'm the first test
Sina: I love that idea.
Alyssa: I'll hold off on creating any accounts until you have that
Matt: once we have that, we want to coordinate the work. So that we can say 'any available testers should focus on plan x'
Matt: for example, someone would write to the list and ask people to work on a test, and then assign them and provide instructions along with due dates.
James: do testers need to join a team for this?
Matt: we need them on the team because the test runner is not viewable publicly. Only people that we have talked to and trained should be running tests.
James: even if someone just wants to review the tests?
Matt: no, anyone can preview tests. That's public.
Matt: for any AT/browser combination, if we have two people run it, and both agree it's good and have identical results, then we would say that the test is ready for wider review
Matt: we would want at least one person running the test to be more experienced, maybe even a mentoring/training program
Michael: do we need to identify someone to coordinate this.
Matt: yes, I'd like to hear someone volunteer
(no one volunteers)
Matt: we will continue discussing this and hopefully someone will volunteer soon
Matt: we have identified the first steps at least