Meeting minutes
<Jem> https://
<Jem> scribe:
<Jem> Scribe?
Site publication
Feed example PR 2775
<Jem> arigilmore: there are testing failure.
<Jem> Howard will look into these.
<Jem> there is flaky part for testing
<Jem> mck: I wonder whether Howard can look at it.
<Jem> howard: I have some thoughts on this and I can add comments
<Jem> mck: do you want me to raise the issue for this?
<Jem> ...wonder about how much logging is done
<Jem> ... we often have to run manually the testing
<Jem> howard: one is more flakier than others
<Jem> mck: it would be great if we can identify the pattern
<Jem> of testing problems.
<Jem> jon: I can do functional testing for feed example.
<Jem> arie: when I ran three times, it worked.
<arigilmore> https://
Bug triage process
Define bug triage process · Issue #2906 · w3c/aria-practices
github: w3c/
Matt_King: On January 16, I listed 8 different sources of work
Matt_King: My goal in this issue is to identify certain areas of work where I think it's very possible for us to do better with the team that we have
Matt_King: ...and make it easier for everybody to help out in the ways that they can
Matt_King: For instance, wouldn't it be awesome if we had more people helping out with the process of triaging issue?
Matt_King: I think issues with the examples are the most common
Matt_King: I'd like to have a clearly-defined bug triage process that allows us to do it more efficiently and more asynchronously. That should free up time during these meetings
Matt_King: Ultimately, this issue will end up on a wiki page
Matt_King: Things we need to do: first, agree that the issue is a bug in the APG code (not in the browser or in the screen reader).
Matt_King: ...if we know that it's reproducible within our scope, we then need to assign a severity and a priority
Matt_King: ...with that information, we'll be able to easily create queries that surface the most important information for this group
Matt_King: I believe that verifying that the bug is reproducible and "in scope" is something someone can do outside of this meeting
Matt_King: Provided they can label and comment on the issue
Matt_King: From there, as a group, we can use the information that was collected and reported asynchronously to make decisions about prioritization
Jem: WCAG does something similar to this
Jem: I think it's a good idea
jugglinmike: it might be tough for non-developers to determine whether a bug is truly in the APG's application code (rather than a browser bug or a screen reader bug)
<Jem> +1 Daniel for pairing or partnership
Matt_King: I think we can document a fairly repeatable process for non-technical folks, at least for ruling out browser bugs (e.g. opening in multiple browsers)
dmontalvo: Maybe assigning two people of differing abilities to triage will be helpful
Matt_King: I've been thinking of adding a new label called "reproducible" and using that as a signal that this first step of the process is complete
<Jem> https://
Matt_King: This group could review bugs labeled "reproducible" and decide if they are dependent on assistive technologies (and close them with an appropriate label in that case)
jugglinmike: Sometimes triaging takes a fair amount of analysis to understand what the reporter is saying. We should document as part of this process that the person verifying may need to formally document their steps to reproduce
Matt_King: Good point!
Jem: Also, we need environment information (e.g. browser version, AT version, OS version, etc.), but reporters do not always provide them. The person performing the triage should also capture that if it isn't present
Matt_King: Great point!
Bug severity labels
Matt_King: At the end of last week's meeting, we had severity ratings of p1, p2, and p3
Matt_King: As I was thinking about this, I think we may want to use those labels to describe priority and separate priority from severity
Matt_King: Because, for instance, a medium-severity issue could be high priority or low priority depending on the popularity of the pattern(s) it effects
Andrea_Cardona: We also tracked data along two dimensions as you are proposing. We used the term "impact" instead of "severity." After a while, though, we found that it felt like a little too much information to track...
Andrea_Cardona: ...so we dropped down to only tracking priority
siri: I like the idea of making it clearer, especially relating to severity. I'm on board!
<Jem> can you hear me?
<Jem> yes to Matt;s answer
<Jem> s/Matt;s anwer/Matt's question.
Matt_King: Okay, then we will move from "p1", "p2", and "p3" to "sev1", "sev2", and "sev3"
Issue triage
Deprecation of the meter pattern
github: w3c/
Matt_King: We didn't deprecate, e.g. the button pattern, after it was added to HTML
Matt_King: Though we do have language which discourages its use
Matt_King: When we deprecated the collapsable list box, we marked it as "deprecated", we removed all internal links to it from other patterns, and we told people on the collapsable list box page, "use the select-only combobox, instead"
Matt_King: Wheras discouraging--on the "button" pattern, we only have language related to discouraging its use
Matt_King: I believe the right answer here is to discourage but not deprecate
Matt_King: Does anyone disagree?
[no response]
<Jem> no disagreement
<Jem> but the prospective for the answer can include the goal of ARIA.
<Jem> re: why we created this example
Matt_King: Hearing nothing, I will take ownership of this issue and report this decision
<Jem> https://
<Jem> https://
Matt_King: I actually don't see a warning on the "button pattern" page. And we don't have a warning on the "button example" page, either
Matt_King: Maybe we do on the "link" page, though. That's where this is more consequential
<dmontalvo> note: Authors are strongly encouraged to use a native host language link element, such as an HTML <A> element with an href attribute. As with other WAI-ARIA widget roles, applying the link role to an element will not cause browsers to enhance the element with standard link behaviors, such as navigation to the link target or context menu actions. When using the link role, providing these features of the element is the author's
<dmontalvo> responsibility.
<dmontalvo> That's the warning message in the link pattern
<Jem> https://
<Jem> "note
<Jem> Authors are strongly encouraged to use a native host language link element, such as an HTML <A> element with an href attribute. As with other WAI-ARIA widget roles, applying the link role to an element will not cause browsers to enhance the element with standard link behaviors, such as navigation to the link target or context menu actions. When using the link role, providing these features of the element is the author's responsibility."
Matt_King: We have a note on the "link" page which "strongly encourage[s]" readers to use the native anchor element
Matt_King: Should we start sprinkling this kind of note in more of the patterns?
siri: I think the more general note about the purpose of ARIA (which the APG already has) is sufficient