Meeting minutes
Update on current sprint (sprint 5)
This sprint ends May 14
Seth: Onboarded Howard and Z
Whole team running at full capacity.
In process of migrating API to graphQL
Howard writing test coverage of whole schema for the API
Example: in past, tight dependency between types of entities, such as every test run had to be associated with an AT and browser version combo.
Now, there is a more generic config entity that could expanded in future.
Nearly done setting up new sandbox environment. Staging and prod are on a W3C server.
Alex setting up additional script to deploy to an AWS instance that can be used as a sandbox to share changes more frequently.
Will enable more frequent testing with stakeholders.
Also improving how we build/spec the environment itself.
Z is starting to clean up the existing harness js file.
This one long file that presents a test and validates the form field values and communicates with parent frame to change page appearnce (e.g., view layer)
Z changing to an APIand port to more maintainable library
Will not change how the test running feels but will enable us to add features
Jes: enables sharing issue between aria-at and aria-at app , e.g., like raise issue button
Z: Currently when the page is rendered, the code has to query the DOM to make changes instead of going back to the JSON objects
This is a primary change
The library will be a modal view controller minus the view
Provides event handlers to maintain state
Can query current test instead of harvesting from DOM
All: discussion of separation of presentation from test data collection
James: What is aim around public consumption of the API
Will there be documentation.
Jes: We document everything we do, whether public is further conversation.
mk: We are doing to support immediate project needs but do not have specific goals for public consumption of API
James: good that it could support rapid prototyping
Seth: Library Z is working is agnostic WRT where data is stored.
Agree can be used for rapid prototyping.
Other question is what is our stance relative to publishig aria-at app API docs
Z, what is format likely to be?
z: Could be NPM lib or something else
James: QIs this a js lib vs a web api?
James/Z/Seth: discussion of mechanics of test rendering from the source csv through html/json to app
mk: how far we from getting rid of generated files in aria-at repo
seth: there is not necessarily dependncy on Z's work for that
seth: Didn't know that we had this strong consensus on getting rid of genn'd files in the aria-at repo.
mk/james: Eager to get rid of them b/c they they generate merge conflicts that are slowing merging in a big way
james: keep in mind the way the gen'd files enable preview
seth: Say we get rid of need for gnerated files tomorrow?
Would this change any thoughts on the test status tracking in the app?
mk: makes it even more important because we will get more draft tests in the the app
seth: What would you say to proposal to a bit more flexible system that allows admins to add tags rather than a drop down that bakes in specific process
mk: consider it but need to be sure the tagging enables process required by the working mode
Community group meeting on Test Writing - new agenda starts here
https://
Assistive technologies like screen readers should inform the user when they reach the end or beginning of a slider
https://
James: should (or how should) a screen reader should convey the values of aria-valuemin and aria-valuemax when a user arrives on a slider?
James: from a technical standpoint, when you have an aria-implemented slider, the screenreader doesn't necessarily know any underlying detail about the slider
James: more importantly, the "aria-valuetext" attribute is supposed to be a human-friendly display version of the value
Matt: i just want to make sure we're on the same page: this is a situation where the aria-at project has an opportunity to nudge vendors into a more user friendly space. if we do this, it would be an instance of that... this means communication is really important. and it sets a higher bar for what assertions we're proposing
jongund: how much do browsers know about valuetext?
James: on mac at least, voiceover gives both valuetext and valuenow
Matt_King: this will probably be a philosophical issue we will get to with combobox too
James: what if valuenow, valuemin, and valuemax all just accepted text?
Matt_King: another issue is that directionality is not known, no way to know if a key press is incrementing or decrementing
Matt_King: I guess ideally the web page indicates this
James: we've implemented this before for education clients
Matt_King: we could update APG example to add something like this (maybe even sounds)
Alyssa_G: just to point out, sound alert wouldn't work for braille users
Matt_King: we need to have a separate approach for sliders with and without valuetext
James: we need to have a separate approach for sliders with and without valuetext
Matt_King: does this mean that if valuetext is set, there's no benefit to valuemin/valuemax/valuenow?
James: correct, for now at least
James: so question becomes: should we add valuetextmin / valuetextmax? or if having valuemin/valuemax be numeric offers no value... should they accept text?
Matt_King: the argument for having numeric valuemin/valuemax is that if an a11y API doesn't support valuetext they can at least calculate a percentage from valuemin/valuemax
Matt_King: we should also provide guidance that valuetext can include a range... leaves ideal format up to content publisher
<jongund> Rating Slider: https://
<jongund> Media Seek Slider: https://
Compositional Test Plan Creation
https://
James: how do we test html semantics alongside aria while reusing as much as possible?
James: for many elements there's a way to do it fully in html, a way to do it fully in aria, and a way to do it in-between
Matt_King: a few different angels: where do the tests come from? who writes them? how do they get checked in?
Matt_King: first off, just to clarify ARIA is in the project title, but in the broadest sense... it should include semantics that come from html and svg
Matt_King: (by the way, this matches evolving APG focus too)
Matt_King: as early as this year, we may see pure html examples from APG
Matt_King: in the abstract, there is a bit of an divergence between the aim of APG (feature-rich, practical examples for authors) vs. the aim of ARIA-AT (testing the most atomic, small examples possible)
Matt_King: in the limit i'd like to introduce two categories of tests: attribute testing and pattern testing
James: in an automated world, testing 300 "attribute tests" wouldn't be a problem