Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: Next meeting: May 6
Publication planning
Matt_King: We really didn't have anything merged and ready to go today
Matt_King: I looked at what's in the queue right now--stuff that people are working on. I think it would be go for us to wait until the end of May
Matt_King: So for now, I've moved the milestone to May 29--the Thursday after Memorial Day
Matt_King: We won't have a meeting on the 27th
howard-e: That week works for me
Matt_King: Great. We'll check with Daniel when he's around. As long as there are no problems on the W3C side, we'll tentatively plan for that
Jem:
Daniel: I believe that publication on May 29 should work
Matt_King: There are four items in the milestone. One is merged and three are on the agenda for today's meeting
Matt_King: I would also like to add more AT support tables in this milestone
Jem:
PR 3249 - Add HTML search to landmark practice
github: w3c/
Matt_King: It appears that there are lint errors
Matt_King: Can someone here look into the errors and maybe push a commit to fix them? I think that is the only thing standing in the way of merge
howard-e: The error reads, "Element 'search' is not allowed as a child of element 'div' in this context"
Matt_King: That's interesting. Why would that not be allowed? Maybe we need to ignore it
Matt_King: I suppose this requires some investigation
Matt_King: There must be something about the content-model for search...
howard-e: I guess if it comes down to ignoring it, I can push a commit to do that.
Matt_King: But it seems strange that we would want to ignore this error if we aren't using the "search" element correctly
Adam_Page: I can look into this one. You can assign it to me
Matt_King: Thanks!
howard-e: The validator is out of date. We pinned to an older version when they released a change that wasn't compatible with our project
Matt_King: It's very possible that this lint error is because our validator is out of date
Matt_King: Could we experiment in a pull request?
howard-e: Yes
howard-e: All of these errors are isolated to the tree grid, the dialog modal, and the combobox
howard-e: I'll do some investigation asynchronously
PR 3258 - Fix slider to remove redundant announcement of value by screen readers
github: w3c/
Matt_King: This is a fix to w3c/
Matt_King: I think it's ready for review. I would love to get it into the next publication
Matt_King: This is only a modification to the HTML file for slider
Matt_King: I can push a commit to get rid of the other change that is present right now
Matt_King: ...or I can ask jongund to do that
Matt_King: I tested this with JAWS already, actually. I'm happy to do some accessibility review on this
Matt_King: But I would like to have one other reviewer
Jem: I know why jongund included that extra change. He fixed the aria-landmark example "resource" page. It should be in a separate pull request, though
Matt_King: Agreed
Matt_King: I'll do screen reader testing with JAWS and NVDA
Matt_King: There are two failing checks in continuous integration
Matt_King: Is the link checker failing because of that landmarks link?
howard-e: Testing locally, both versions of that link fail for me
Matt_King: I think I would probably remove that change. I would even be fine with merging with the failing link and fixing it in a separate pull request
Jem: Agreed
Jem: I can review the change to the slider. I will make sure that there are no unexpected changes, like in the visual presentation
Jem: I don't see any change to the visual presentation
Matt_King: Maybe this is just a simple 1-minute review
Matt_King: When I tested with JAWS, it was doing exactly what I was hoping for, which is pretty awesome
Matt_King: I've added you as a reviewer, Jem
PR 3251 - New expandable region pattern
github: w3c/
Matt_King: Did we want this to be a separate pattern, or would it be another form of disclosure?
Matt_King: It could be one example that's under the "disclosure" pattern, but if it is a truly distinct pattern, then I'm happy to have a separate page for it
Matt_King: ...in that case, as howard-e was explaining, we need to have a "pattern" file and a sub-directory for the example, and an example file
Matt_King: Though even then, we will probably make a note that it is related to the "disclosure" pattern
Adam_Page: It hadn't occurred to me to add it as an example of an existing pattern
Adam_Page: I don't have a strong opinion on this one. I added it as a pattern only because it was originally pitched that way. I don't think we ever really discussed if that was the best option
Adam_Page: I've updated this with howard-e's help so that it builds as it should
Adam_Page: Basically, I did the initial implementation and that was it. I am mainly looking for feedback on the example itself, knowing that I will need to go back and fill out the documentation (and image, etc.) accordingly
Adam_Page: There is some appeal to me in making this another example within the "disclosure" pattern. It really is a disclosure
Adam_Page: Again, I don't have strong opinions on this, and I wasn't present for the original discussion
Adam_Page: But if I understand the impetus, this was intended as a sort of preferable way for the use case that many people were satisfying by stuffing a lot of stuff into buttons
<Jem> Jaws has imposter syndrom. LOL
Matt_King: When I tried to collapse, JAWS lost its place. It went to "impostor syndrome". The performance isn't great, either
Matt_King: I don't know what JAWS is doing here, actually...
Adam_Page: I haven't tested in JAWS. I developed in Mac and used VoiceOver. It all seems to be working, there
Matt_King: Calling this an "expandable region" is kind of interesting to me
Matt_King: There's a region, and it has a little bit of content inside of it, and it has this option to make the content inside the region bigger
Siri: It looks like an accordion, no?
Adam_Page: It really is, fundamentally, a disclosure--like, an accordion
Adam_Page: The quirk is that the thing that visually is inviting the user to expand is structurally rich. We're using JavaScript to enlarge the clickable region
Jem: I don't think this is an accordion design pattern. This is a disclosure.
Matt_King: I don't understand why it has anything to do with the region
Matt_King: The "details" button feels like an ordinary disclosure
Matt_King: So there's something about the visual presentation that says you can click on a larger area
Matt_King: If I wanted to code this, I would say, "here is a landmark region that says 'fire to flare'" and then within that region, I would place a disclosure
Siri: If we have to provide a region for the container inside, I don't think we need to go into that much detail
Matt_King: It feels to me like this goes in the "disclosure" pattern
Adam_Page: It certainly has a lot in common with "disclosure". If we were to make it its own page, then that new page would have a lot in common with "disclosure". It would maybe be redundant
Adam_Page: Maybe we just call it a "rich disclosure". The differentiating factor is that the thing which expand the disclosure is rich--it is visually showing much more
Matt_King: Right, but from a screen reader user's point of view, there is no difference
Adam_Page: Yeah
Adam_Page: That's where I was interested to get some feedback on the example. That's where I made some editorial decisions about what the screen reader should be
Jem: What screen reader user experience are you referring to?
Matt_King: It's different from the accordion because there, we use a heading and make the whole heading clickable.
Matt_King: You can do the same thing with the accordion pattern. You could show more content than the heading in its collapsed state.
Matt_King: That's feasible, and it's covered in the pattern
Matt_King: In this case, this is a region with some content in it. A region that contains a heading and some text. And then following the text, there is a disclosure button. As a screen reader user, it doesn't feel any different from any other instance of a disclosure
Matt_King: The reason they wanted it in the APG has to do with the approach to coding it, where you have a "section" element, and the idea is that everything inside of that section is clickable.
Adam_Page: I think it was especially a reaction to how, in the real world, people are stuffing tons of stuff full of stuff that they shouldn't (and risking access issues) just to make that entire surface clickable
Matt_King: So the alternative is that some people might use a button where you have a section?
Adam_Page: Yes, that some people might stuff everything in my regions into a button
Matt_King: So the idea is to replace the button with a clickable section, and say "here's how you do it"
Adam_Page: And to do that without inventing anything new for ARIA or HTML--just to solve the use case with things that already exist
Matt_King: It looks to me like what you have for the details is a button element that doesn't look at all different from any of our "disclosure" buttons that we already have in APG
Adam_Page: Yes, that's right
Matt_King: When Scott presented this, I had the impression that there was something simpler or different about the coding than having to make a button. I guess not
Adam_Page: Scott made a code pen really early on when he made the issue for APG. I referenced that, taking it an beefing it up
Adam_Page: I will investigate what's going on with JAWS
Matt_King: I am using a pre-release version of JAWS, so it may be due to that
Matt_King: This is really just a different visual design for a disclosure that has a bigger click target
Adam_Page: Yes, I think that's a fair summary
Matt_King: Is the issue here about naming and helping people understand that they can have large, rich click targets?
Matt_King: Maybe we call this a "disclosure region" instead of a "disclosure button"
Adam_Page: Jem called out that there is the Bootstrap "Card". That is a common UX paradigm
Matt_King: So maybe we call it an "expandable card"
Adam_Page: That could work
Matt_King: I think the first step is to move it into the "disclosure" example directory
Matt_King: Then we can avoid creating a whole new pattern
Adam_Page: Sounds good
Matt_King: We ought to be able to get this into the next publication. I'll see if I can mess around with words
<Daniel> w3c/
ask Daniel
Daniel: I put a comment for us to think about what we want the screen reader user's experience to be
Daniel: As you arrow down through the things, you could press "enter" to expand. Making this go to the button and then hitting "enter" on that--maybe we should consider efficiency
Daniel: And for what it's worth, I don't experience any lag when testing with NVDA (though I'm using an NVDA beta)
Matt_King: If you're reading this with a screen reader, even if you knew that there was something expandable inside of this region before you got to this button, how would you know that you want to expand it before getting to the button? I'm presuming that you would want to read the content...
Matt_King: I'm trying to grasp what the alternatives might be and why they might be desirable
Adam_Page: I have to confess that the "clickable" announcement is a little mysterious to me, still. I don't know if it happens in VoiceOver at all
Adam_Page: Are JAWS and NVDA trying to be "smart" in the sense that if they see a "click" event listener on an element that is not typically focusable, do they bubble that information up?
Daniel: NVDA has that behavior enabled by default, but I turn it off
Matt_King: I do, too
Daniel: There's a setting in NVDA where you can actually turn it on or off whether you want "clickable" items announced
Daniel: As Adam_Page was saying, it's whenever they find a "click" event listener
Jem: Daniel shared that as a comment to issue 3215
Matt_King: JAWS and VoiceOver don't announce "clickable" by default, and a lot of NVDA users turn it off
<Jem> w3c/
Matt_King: Thank you for the excellent discussion! This is great
Adam_Page: For my next step, I will do some JAWS testing and update the pull request to make this an example of the disclosure pattern
Matt_King: Awesome, thank you!