19:03:02 RRSAgent has joined #aria-apg 19:03:06 logging to https://www.w3.org/2024/01/23-aria-apg-irc 19:03:06 RRSAgent, make logs Public 19:03:07 Meeting: ARIA Authoring Practices Task Force 19:03:15 rrsagent, make minutes 19:03:16 I have made the request to generate https://www.w3.org/2024/01/23-aria-apg-minutes.html Jem 19:04:20 howard-e has joined #aria-apg 19:04:46 siri has joined #aria-apg 19:06:26 https://github.com/w3c/aria-practices/wiki/January-23%2C-2024-Agenda 19:06:42 present+ 19:06:48 arigilmore has joined #aria-apg 19:07:10 jongund has joined #aria-apg 19:07:17 present+ 19:07:29 present+ 19:07:41 present+ 19:07:50 Matt_King has joined #aria-apg 19:08:04 present+ 19:08:37 present+ Daniel 19:09:32 present+ 19:10:04 scribe: 19:10:17 Scribe? 19:10:41 scribe:Jemma 19:10:49 Topic: Site publication 19:11:06 subtopic: Feed example PR 2775 19:11:20 arigilmore: there are testing failure. 19:11:30 Howard will look into these. 19:11:59 there is flaky part for testing 19:12:14 mck: I wonder whether Howard can look at it. 19:12:33 howard: I have some thoughts on this and I can add comments 19:12:50 mck: do you want me to raise the issue for this? 19:13:12 ...wonder about how much logging is done 19:13:28 ... we often have to run manually the testing 19:13:42 jugglinmike has joined #aria-apg 19:13:51 present+ jugglinmike 19:13:59 howard: one is more flakier than others 19:14:18 mck: it would be great if we can identify the pattern 19:14:34 of testing problems. 19:14:45 jon: I can do functional testing for feed example. 19:15:16 scribe+ jugglinmike 19:15:55 arie: when I ran three times, it worked. 19:16:20 https://github.com/w3c/aria-practices/actions/runs/7546522554?pr=2775 jobs run on the pr 19:16:37 Topic: Bug triage process 19:16:51 subtopic: Define bug triage process · Issue #2906 · w3c/aria-practices 19:17:01 github: https://github.com/w3c/aria-practices/issues/2906 19:17:29 Matt_King: On January 16, I listed 8 different sources of work 19:17:54 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 19:18:09 Matt_King: ...and make it easier for everybody to help out in the ways that they can 19:18:28 Matt_King: For instance, wouldn't it be awesome if we had more people helping out with the process of triaging issue? 19:18:43 Matt_King: I think issues with the examples are the most common 19:19:11 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 19:20:03 Matt_King: Ultimately, this issue will end up on a wiki page 19:20:52 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). 19:21:13 Matt_King: ...if we know that it's reproducible within our scope, we then need to assign a severity and a priority 19:21:42 Matt_King: ...with that information, we'll be able to easily create queries that surface the most important information for this group 19:22:10 regret+ mark, bryan, curt 19:22:29 Matt_King: I believe that verifying that the bug is reproducible and "in scope" is something someone can do outside of this meeting 19:22:45 Matt_King: Provided they can label and comment on the issue 19:23:34 Matt_King: From there, as a group, we can use the information that was collected and reported asynchronously to make decisions about prioritization 19:23:46 Jem: WCAG does something similar to this 19:23:58 Jem: I think it's a good idea 19:34:15 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) 19:34:34 +1 Daniel for pairing or partnership 19:34:58 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) 19:36:06 dmontalvo: Maybe assigning two people of differing abilities to triage will be helpful 19:36:55 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 19:37:01 https://github.com/w3c/aria-practices/labels 19:38:54 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) 19:41:22 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 19:41:31 Matt_King: Good point! 19:42:33 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 19:42:39 Matt_King: Great point! 19:42:49 Topic: Bug severity labels 19:43:24 Matt_King: At the end of last week's meeting, we had severity ratings of p1, p2, and p3 19:43:56 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 19:45:28 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 19:45:48 present+ Andrea_Cardona 19:47:01 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... 19:47:18 Andrea_Cardona: ...so we dropped down to only tracking priority 19:49:20 present+ siri 19:49:37 siri: I like the idea of making it clearer, especially relating to severity. I'm on board! 19:49:56 can you hear me? 19:50:13 yes to Matt;s answer 19:50:36 s/Matt;s anwer/Matt's question. 19:50:54 Matt_King: Okay, then we will move from "p1", "p2", and "p3" to "sev1", "sev2", and "sev3" 19:51:44 topic: Issue triage 19:52:09 Subtopic: Deprecation of the meter pattern 19:52:13 github: https://github.com/w3c/aria-practices/issues/2905 19:52:48 Matt_King: We didn't deprecate, e.g. the button pattern, after it was added to HTML 19:52:52 rrsagent, make minutes 19:52:53 I have made the request to generate https://www.w3.org/2024/01/23-aria-apg-minutes.html Jem 19:53:13 Matt_King: Though we do have language which discourages its use 19:54:27 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" 19:55:01 Matt_King: Wheras discouraging--on the "button" pattern, we only have language related to discouraging its use 19:55:15 Matt_King: I believe the right answer here is to discourage but not deprecate 19:55:21 Matt_King: Does anyone disagree? 19:55:34 [no response] 19:56:40 no disagreement 19:56:59 but the prospective for the answer can include the goal of ARIA. 19:57:16 re: why we created this example 19:57:16 Matt_King: Hearing nothing, I will take ownership of this issue and report this decision 19:58:23 https://www.w3.org/WAI/ARIA/apg/patterns/meter/ 19:58:50 https://www.w3.org/WAI/ARIA/apg/patterns/meter/examples/meter/ 19:59:05 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 19:59:26 Matt_King: Maybe we do on the "link" page, though. That's where this is more consequential 19:59:48 note: Authors are strongly encouraged to use a native host language link element, such as an HTML 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 19:59:48 responsibility. 19:59:58 That's the warning message in the link pattern 20:00:28 https://www.w3.org/WAI/ARIA/apg/patterns/link/ 20:00:54 "note 20:00:54 Authors are strongly encouraged to use a native host language link element, such as an HTML 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." 20:00:55 Matt_King: We have a note on the "link" page which "strongly encourage[s]" readers to use the native anchor element 20:01:56 Matt_King: Should we start sprinkling this kind of note in more of the patterns? 20:02:20 siri: I think the more general note about the purpose of ARIA (which the APG already has) is sufficient 20:11:10 Zakim, end the meeting 20:11:10 As of this point the attendees have been howard-e, Jem, jongund, arigilmore, Matt_King, Daniel, siri, jugglinmike, Andrea_Cardona 20:11:12 RRSAgent, please draft minutes v2 20:11:14 I have made the request to generate https://www.w3.org/2024/01/23-aria-apg-minutes.html Zakim 20:11:20 I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent. Goodbye 20:11:20 Zakim has left #aria-apg 20:11:26 RRSAgent, leave 20:11:26 I see no action items