Meeting minutes
Setup and Review Agenda
https://
Jem: No meeting September 23
Jem: Next meeting: September 30
Jem: Any requests for change to agenda?
Jem: Hearing none, we'll use the agenda as scheduled
Publication planning
Matt_King: Besides the items on today's agenda, everything else in the milestone that we were expecting to get landed is done!
<Jem> https://
Jem: For the October publication plan, I only see "skipTo" from jongund, but I assume there will be more
Matt_King: We also have the "color settings"
PR 3328: Add Quantity Spin Button
github: w3c/
Matt_King: jongund wrote a comment about limiting the input
Matt_King: That's interesting because it had previously been limited
jongund: I'm satisfied with the current solution--if you've discussed it, then that's fine with me
Matt_King: I added several suggestions for editorial changes, and I think they're very straightforward
Adam_Page: Yes, I reviewed them all and accepted them all
Matt_King: Excellent
Matt_King: One little thing I noticed: if you back-tab into it, then the plus sign gets focused
Adam_Page: I couldn't reproduce that, but I'm on macOS without a screen reader running. I'm going to spend more time with it after this call
Matt_King: It's a minor thing, though; I think we can merge without addressing it
Matt_King: Because we have aria-valuemin and aria-valuemax specified, and the aria-describedby is giving the same information, they create redundant speech for screen readers that automatically announce descriptions
Matt_King: So my suggestion is to remove the relationship
Matt_King: I shared some examples of the speech that is generated as a result of having description, min, and max all specified
Adam_Page: I asked a coworker of mine to kick the tires on this thing several days ago, and he gave me the same feedback
Adam_Page: The one potential downside I see is that not all screen readers announce min and max (in particular, macOS VoiceOver does not)
Adam_Page: For those cases, aria-describedby is the best way to deliver that information
Matt_King: We test this in ARIA-AT, but I thought that VoiceOver was not announcing descriptions automatically...
Adam_Page: They are, now--the last time I checked, aria-describedby is getting immediately announced
Matt_King: I know Vispero has done a lot of work to get proper support of min and max on sliders, and that they would want all controls to have equivalent support
Matt_King: I guess we should just press this issue with Apple
Matt_King: If Apple wanted to push back on Vispero's position for some reason, then maybe we would want the APG to espouse the use of descriptions
Adam_Page: I'm good with it. It feels quite comparable to aria-errormessage
Matt_King: Okay. Do we want to give audiences guidance that is more durable? Or do we want to degrade the experience for some screen reader users in order to avoid the potential bug in some screen readers?
Siri: Even for description, when I check, it says that we have to enable a setting--otherwise, it may be skipped
Matt_King: Well, ARIA-AT definitely tests with defaults. So if that behavior isn't enabled by default, then it would be reported as a bug in that project
Matt_King: This conversation is really similar to the "abbr" conversation. However, in this particular case, because interoperability is ongoing (and the conversations with screen reader vendors are active), I feel giving more feedback on the current behavior
Adam_Page: As an APG reference, it does feel a bit provocative to have an input with visible help text that is plainly help text and to have them not related with aria-describedby.
Adam_Page: I would like to explicitly explain that choice
Matt_King: Yeah, you can do that within the existing bullet point that your patch is including
Adam_Page: I can complete this by tomorrow morning
Matt_King: We'll put in a "publication" pull request tomorrow, but if it doesn't happen until Thursday, then that doesn't matter
Daniel: Sure, a few days is not a problem
Matt_King: I'm okay even if we submit the pull request on Thursday
howard-e: Tomorrow or Thursday will both work for me
Matt_King: Okay, so Adam_Page will make the changes, then I will review it, then once everything is good, I will merge and let howard-e know that everything is ready for publication
Daniel: It's reading the 1 to 8 hint. I'm in macOS Tahoe. Since you're mapping, this behavior doesn't surprise me.
Matt_King: Daniel, you clearly have that setting for speaking descriptions enabled. Do you know if you proactively turned it on?
Daniel: I did. I don't think it's the default
Matt_King: Okay! This is going to be a really good discussion to have with Apple. Hopefully we'll be aligned!
Spell checking CSS and fix for 'invalid'
github: w3c/
Matt_King: So two things got raised in this issue
Matt_King: The first is that is seems we have a fix by modifying the regular expression (which is the fix you made)
howard-e: The pull request is no longer marked "draft"; it is ready for review, now
howard-e: I have some additional questions that I left there, but we don't need to answer them before merging
Adam_Page: I can review this
Jem: I've assigned Adam_Page as a reviewer
Matt_King: As for CSS spell-checking
Matt_King: The momentum last week was, "why are we checking the CSS spelling? Maybe we don't need to."
Matt_King: howard-e has reported that there are a fair number of comments in the CSS, along with class names where spell checking could be of value
howard-e: Last week, I was on the side of wanted to remove spell checking for the CSS because I knew we have style linting, and there's a lot of overlap with that process
howard-e: But after reviewing the code base this week, I started to appreciate the value of having just a check
howard-e: So I think it's safe to keep the spell checking on CSS files
Matt_King: I had personally forgotten all about CSS content. I don't know if we're using that, but it sounds like a strong motivator
Adam_Page: Everything howard-e just shared is convincing to me
Matt_King: I would imagine that if there were any W3C custom configuration for cspell, then Nick (who commented here) would know
<Adam_Page> w3c/
Jem: Nick has saved us multiple times
howard-e: I would love to meet Nick! I always appreciate when he passes through
PR 3362: Carousel Pattern: Fix inconsistency in use of digits and number words by mehrazmorshed
github: w3c/
Matt_King: This was an issue raised by someone outside of the Task Force
Matt_King: It's a simple pull request. I was about to approve it, but I wanted to ask this group a question
Matt_King: In the text that's being changed, we have some places where the word "two" (t-w-o) was used, and other place where the number "2" was used
Matt_King: This person made the change so that in all cases in this text, we're using the digits instead of the spelled-out words. My gut would have been to go in the other direction (that is: to change the digits to words), but since in this particular case, we're talking about using the numbers as identifiers, then it seems consistent with style guidelines
Jem: I support that
Matt_King: There's also a W3C editorial practice, which at one time was aligned with the Chicago Manual of Style. Typically, we say that most of the time, yo u spell out number. But again, because we're using the numbers as identifiers (rather than as numbers), this case seems different
Daniel: When I was an editor, I knew more than I do, now. It seems reasonable, but I'll take a look
Matt_King: Do you mind being designated as a formal reviewer?
Daniel: Sure. This is not slated for the September milestone, right?
Matt_King: That's correct; it is not. You can take your time
Matt_King: Keep in mind that it's just a one-liner, though
[general discussion about a regression in the accessible user experience of the "patch review" user-interface of GitHub.com]
Jem: I've assigned Daniel as a reviewer
Issue 3363: Clarification of accordion documentation
github: w3c/
Matt_King: In this one, the reporter is just asking what we mean in the documentation. When we say "enter" and "space", we don't put an "and" or an "or", we just have a row in a table. We do use those conjunctions in some prose, but I don't know how consistent we are
Matt_King: They're using a library where only "enter" is supporting. They are asking if we always mean "and" or "or"
Matt_King: My understanding is that we always mean "both"
Adam_Page: Agreed. I've always interpreted this from the user's perspective--that the user may press either one
Matt_King: That's how I've always tested, personally, and it's also how we test in ARIA-AT
Matt_King: Maybe we could encourage them to submit a pull request to add support for the space bar in Ant Design
Matt_King: I suppose that we should remind people that APG is not normative--it's not a requirement; it's just what we recognize as a good practice