Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests for change to agenda?
Adam_Page: If there's time, I'd like to add an agenda item about the dialog
Matt_King: Ah, yes. I saw that, but I was a bit concerned about whether we'd have time to discuss it during today's meeting
Matt_King: I don't know if we have enough different perspectives represented in this call. I'd like to have at least one or two other screen reader users
Matt_King: I think things like this might require special calls where we invite a specific audience--almost like an ARIA deep-dive
Matt_King: Maybe the point of the agenda item would be about how to foster the appropriate discussion
Matt_King: Next meeting: August 12
Publication planning
Matt_King: I set up a milestone, but I haven't started adding things to it, yet
Matt_King: I think things in today's agenda could end up getting added there
Matt_King: We've been working on this one pull request that has been collecting a lot commits. I haven't had the bandwidth to determine what it needs to get it on the background
Matt_King: jongund is a primary author of that one
Matt_King: My main concern is about simplifying the messaging. It currently feels a little too complicated. It's a lot of information, and I'm unsure that it's all necessary to helping the audience
Matt_King: w3c/
PR 3306: Rename Javascript to JavaScript
github: w3c/
Matt_King: We requested the contributor to make some changes, and they told us that they made the changes
Matt_King: howard-e have you re-reviewed this since then?
howard-e: Not yet, no. I'm seeing that there is a duplicate pull request. Pull request #3317
howard-e: It's authored by the same contributor
howard-e: It seems to be identical
howard-e: They pushed the original plus the fix into this new pull request
Matt_King: If possible, I'd like to get the fix into the original pull request so that the history is easier to follow
Matt_King: There's a nitpick about cspell. It's a one-line change that isn't directly related, so I'd love it if someone can do it in a separate patch
arigilmore: I can do that
Matt_King: Thank you!
PR 3309: Proposed changes to focus handling in editor menubar
github: w3c/
Matt_King: Once I read the detailed explanation (thanks arigilmore for requesting that), I understood that these are great changes
arigilmore: I could only see the changes when running it locally. Nothing was different on the deploy preview
arigilmore: Adam_Page expects that something is broken with the deploy preview system
arigilmore: But it all looks good when running locally
Matt_King: And it says that all checks have run and that all checks have passed
arigilmore: The code looks good to me
Matt_King: Do we need any other kind of review?
Matt_King: It doesn't change look or appearance
arigilmore: Right. it just alters the behavior in certain circumstances
Matt_King: I would like to be able to test this before we do the final merge
howard-e: This is an issue with the Netify cache
howard-e: I recently had an idea about what is going wrong, and I'm going to investigate that theory today
howard-e: But for the short-term, I can manually trigger the build for this pull request
arigilmore: We were observing two elements with "tabindex" set to zero
Matt_King: Thank you so much for your work on this; this is great!
Issue 3293: Adding "Read This First" link to the top of each pattern page
link: w3c/
Matt_King: howard-e worked on this, and there are two pull requests: one in the "content" repository, and one in the "build" repository
<jongund> Sorry I am late
Matt_King: You added a script that does the insert after the "h1" element
Matt_King: On the "patterns" page, we have a graphic in the content. We're leaving that graphic out in the other pages
howard-e: We have about 32 "patterns" pages
Matt_King: What does the pull request in WAI ARIA Practices do?
howard-e: that updates the content itself. It's included in the generated files for the WAI APG repository
howard-e: It just re-includes the script. It generates Markdown files for Jekyll. And it also removes the static inclusion of that "read thie first"
Matt_King: Okay, great
Matt_King: I feel like we should have at least one other person reviwing
jongund: I can take a look
Matt_King: Thanks!
Matt_King: The pull request is #3320 w3c/
Matt_King: Hopefully we can merge this next week
PR 3328: Add Quantity Spin Button
github: w3c/
Adam_Page: So this kicked off a couple weeks ago when someone filed an issue. They challenged us on a WCAG-non-conforming target size with our spin button date picker example. And they also pointed out that the ARIA text suggests the use of text input
Adam_Page: We decided to replace the example IT's a very traditional spin button that is a numeric field which captures an integer and includes "plus" and "minus" buttons to increment and decrement. It satisfies target size. A keyboard can tab into it and type in a value directly I took care to make sure that voice control works well. The "plus" and "minus" buttons are omitted from the document tab flow, but they are still present in t
he accessibility tree
Adam_Page: Also a little bit of high-contrast mode finesse
Adam_Page: I think that covers it! I also updated the "accessibility features"
Matt_King: So you also replaced the date-picker spin button on the "patterns" page
Matt_King: With collapsible listbox, we deprecated an example. So we have an editorial precedent for deprecating examples.
Matt_King: We could deprecate this or delete it entirely
Matt_King: We deprecated that listbox example because we thought people might be using it
Matt_King: In this case, though, I don't know if there's value in deprecating versus just deleting
Matt_King: The only way to get to that deprecated listbox is via the index
Matt_King: We changed the title to say "deprecated" so that the deprecation is apparent even when it appears in the index
Matt_King: But the other option is just to remove
Matt_King: I don't know which is better in this case
Adam_Page: Me neither. I'm just learning about this deprecation pattern
Matt_King: I kind of like having a record of deprecation even if we don't think people are using it
Matt_King: It's not like we have a lot of deprecated content like this which is acting like baggage...
Adam_Page: Yeah, that sounds good to me. I will restore it and add the deprecation message
Matt_King: We'll review informally while you make that change, and assign formal reviews next time
Adam_Page: Sounds good
Matt_King: This is awesome. You delivered quickly and very comprehensively Thank you, Adam_Page!
PR 3213: Update SkipTo feature to version 5.8
github: w3c/
Matt_King: A few weeks ago, I gave jongund some feedback (especially on group labeling)
Matt_King: The skipTo feature that is at the top of every page comes from a shared script inside of content/shared/js
Matt_King: jongund copies that in directly from what he maintains in his skipTo repository
Matt_King: This is version 5.8 of the script
Matt_King: The pull request has been updated,but I can't tell what exactly has changed
Matt_King: As a screen reader user, I have found the extra information in the group label to be not helpful
jongund: There is in the actual group label, information about the number of headings and labels
Matt_King: I'd like it removed from the screen reader label of the group
Matt_King: When I go from one group to another group, JAWS reads the group label before it reads the menu item. So I'm on the APG homepage, and I open the skipTo. When it first opens, it's not particularly distracting. But when I'm navigating the menu (I get to "Complimentary" which is the third landmark
Matt_King: This might be a general problem with putting groups in menus, but it just makes it harder to understand the menu
jongund: Should we give the group an empty heading?
Matt_King: I think, since there is a group of landmark regions and a group of headings...
Matt_King: I think if it just said "landmark regions" instead of the number of landmark regions. And "headings".
Matt_King: Maybe the thing that makes it hard to understand (at least to me) is adding the number. Because there are are a lot of numbers elsewhere in this text
jongund: Okay, I can remove the number
Matt_King: I don't care if you leave the number in visually; it's just redundant information for a screen reader user
jongund: The reason for the number is because there are so many items that they can visually fill up the screen
jongund: Regarding the scrolling behavior; people can try it out and share some feedback
Matt_King: What does this mean, "labels are always visible"?
jongund: If there are a lot of landmarks on the page, you wouldn't even see the headings group
jongund: I clip them so that if there's more, there will be a scrollbar
Matt_King: So it's separately visually scrollable with the mouse or keyboard
jongund: That's right
jongund: The menu is visually smaller, and there's an "about skipTo" message at the bottom
Matt_King: Oh, right. That should say something about it being an external link. Right now, it just says "about skipTo.js". It doesn't say that it's going to another website
jongund: It only opens a dialog
Matt_King: Ah, yes. And from there, it gives you an option to go to another site
Matt_King: Okay, so no one is going to leave APG without realizing that they are leaving APG
Matt_King: Okay, we need some reviewers
Matt_King: We don't need a code review (this code isn't meant to be pedagogical code for others; it's only infrastructure)
Matt_King: Though if anyone wants to review the code, that's great!
Matt_King: I'm mostly interested in the functionality, both with and without a screen reader
arigilmore: I can try
Matt_King: Thank you, arigilmore! I will assign you
Issue 1772 - dialog tab rings
github: w3c/
Adam_Page: We had editorial feedback about trapping of dialogs
Adam_Page: We were updating one of the "understanding" sections for WCAG
Adam_Page: My knee jerk reaction was to come back here and make the APG pattern imitate the native dialog. And remove the keyboard trapping from the APG example
Adam_Page: When I started to do a little research, I found a four-year-old debate of the merits of trapping versus non-trapping of dialogs
Adam_Page: One of the more recent (and not mentioned in that discussion) reasons the HTML group chose not to trap focus in the dialog is that the pattern has been used maliciously to trap users inside the model and convince them to disclose sensitive information
Matt_King: I don't know how that would be possible given that the dialog is required to have a close/cancel button (which the HTML dialog could absolutely enforce)
Matt_King: That sounds like a red herring of an argument to me
Adam_Page: I'm curious about it myself. I took it at face value that maybe the discussions in the HTML was based on custom implementations that they had seen, which existed prior to the standard
Matt_King: Certainly someone could do that with JavaScript. I won't even try to wear an editor's hat, here. But I do have very strong opinions
Matt_King: I haven't met a single blind screen reader user who thinks it's a good idea to be tabbing away into the chrome. It's so disorienting!
Matt_King: For one, you don't have good clues that you've left the webpage
Matt_King: There are a gazillion keys for getting out of the web page, just like there are a gazillion keys for getting out of the content of a native app
Matt_King: Now that we treat the web page like the content of a native app... Why does the browser thing it's so special that it thinks it should be in the tab ring?
Matt_King: That's just my take--are you using the browser, or are you using the web page?
Matt_King: When you open a native app, you can't tab out of the native app to the Finder or the dock, etc.
Adam_Page: I don't think it goes beyond me. It caught my curiosity, but no one is champing at the bit to make any changes here
Adam_Page: We can certainly just drop it
Matt_King: I wish there was a way to get the native dialog to work like the APG dialog!
Adam_Page: I'm okay leaving it there. I'll regroup with the Task Force and let them know that we had this conversation
Matt_King: Okay, we're out of time. Thanks to everyone for all the great contributions!