Meeting minutes
Matt: does anyone have any additions for the agenda?
ST: I have some questions about a blocker for Bocoup on the redesign
Matt: that fits into an existing topic, let's talk about it then
APG Issue Triage
MK: Jemma and I are looking at existing issues, but also adjusting the query to go further back in time. By the end of the year, maybe we'll eat through a portion of the giant backlog
MK: the first one, the datepicker dialog uses aria-modal without making the rest of the page unavailable
issue link: https://
SH: I think this is a disconnect between what aria-modal should do and what it does.
JN: it looks like the base page isn't inert, I can click through to the page. So it looks like it shouldn't be inert.
MK: normally a datepicker wouldn't make a page inert, right?
JN: right, not normally. They're semi-modal in some ways
SH: normally when I've done this, it's been because the popup is at the end of the DOM, but I don't think that's the case here?
MK: I think this deserves some discussion, because this might legitimately be a non-modal dialog. There might not be a use where you need to move back and forth with the page... I think this deserves a bit of discussion
MK: I'm going to add the agenda label
MK: next, https://
SH: from comments, it looks like this was resolved and we can close?
MK: let's do that, I'll mark it closed
MK: next, fieldset button issue: https://
SH: am I remembering right that Scott was doing some work to make figcaption not participate in the accname for figure?
JN: it's going to be related by details
MK: I think the point of this example is to use figcaption
SH: I think if figcaption no longer named figure, this issue wouldn't be an issue anymore, and we could use figcaption
JN: correct
MK: I think one of the reasons we made it this way was because we wanted to test figcaption
JN: OK, but that's different from the figcaption, the disclosure is the...
JN: is the button, which is a child, and then that has just a controls relationship. I don't understand why that would
MK: yeah, that button should just say data table for chart
MK: but it's reading the whole thing
JN: that sounds like a JAWS bug
JN: I don't understand why it would be reading the parent element when you focus on a button. That's just bizarre
MK: you know how JAWS will read the name of a container when you tab in? I think that's what's happening
MK: if we did fix the bug Sarah was talking about
JN: or if Chrome fixes their bug so they don't name the figure by the figcaption
JN: currently the figure has the accname of the long text
MK: so there's two questionable behaviors. One is whether JAWS should read the container label, and the other one is the Chrome behavior
MK: is anybody willing to take on responding to David here?
JN: should I put a link to the HTML AAM issue in?
MK: yeah, that would be great. In the issue?
JN: yeah
MK: that would be great
Siri: I had a question. If it has a figcaption, if you use an img the alt can be empty because figcaption is providing a description. So if you're removing figcaption from the description, how do screen readers know?
Siri: I thought the purpose of figcaption is if you provide a caption below the image, it can be treated as a description for the image
MK: yeah, a detail-structured description, not a name
JN: not even a description, because it often includes structure
MK: yeah, not even a description. Details, which I consider another form of description, which we don't include in the name and description calculation
MK: is there anybody that I could assign this to?
MK: assigning myself
MK: ok, going to overly verbose permalinks. We've closed this -- https://
MK: I'm just going to close it
MK: next, hybrid navigation: https://
MK: What is hybrid navigation? I don't understand the title of this issue
MK: oh, is this the disclosure navigations that you worked on, Sarah?
<siri> https://
SH: I think so
MK: this is the one with top-level links
<siri> From scott's blog:A figcaption provides a caption, or summary, to the content the figure contains. The figcaption should become the accessible name to the figure element, unless an aria-label or aria-labelledby attribute are used on the figure instead. The figcaption may be placed before or after the primary contents of the figure, however it must be a direct child of the figure element.
MK: his first suggestion is adding the menu opening on hover. We talked about this, didn't we say we didn't want to do that explicitly?
MK: a version where the down arrow isn't visible except on keyboard focus, and an example with both those features
MK: does this need further discussion? Is this stuff we want to consider?
MM: I'd be in favor of not doing that. I think the version where the down arrow is only visible on focus -- I'd rather have everything the menu can do be visible on the outset, so you don't have to poke around and try to find what it can do
MK: often when we don't do things that are out in the wild, it's because we don't think it'll help accessibility
MK: my first thought is if we do this, will it cause any WCAG failure? I don't think the hover one would, I don't know what to think of that so I'll let you mouse people offer opinions
MK: I think one of the reasons we talked about not doing hover is because we talked about screen magnifiers so you shouldn't do any hover until you at least do one click
MM: and that's a better way to do it (only on click). The ones I've seen where it does expand on hover, it's not obvious that the top-level link is clickable. So if we do that, we want to make sure that the top-level link can obviously be clicked, but I don't like htem as a sighted sometimes-mouse user
JN: I'm of the opinion that there are an infinite number of variants that any of these can do, and we shouldn't attempt to do all of those variants
MM: I feel like this is one of those things where someone says "look at this company, they do it!" and it's not always the best example. I don't know if we should be supporting that necessarily
MK: so I guess a thoughtful response here, we could just use the justification you said James. If we wouldn't do these things for a11y reasons, I want to state that in our response
MK: I don't know if I can come up with that myself. I don't know if we need some agenda time to talk about it more. We'll get an infiinte supply of feedback over time
JN: for any of these, if anyone wants to supply a well-formed completed PR that we can tweak, that's fine. But if someone's just going to ask if we can do this, this, etc. we have so many things to do that we can't do all these tweaks to stuff when we have plenty that isn't covered at all
MK: I'm going to assign myself and write a response
Open Pull Requests
MK: tabs examples, I didn't make any progress with that this week, had a chrome bug
https://
MK: I want to bring up the accordion PR to ask you, Sarah
MK: we were making progress on this PR prior to publication
MK: then we didn't quite finish, and I don't remember all the reasons here
MK: don't have all the reviews, I can see
https://
SH: from what I remember, everything that's been commented has been addressed
MK: so we should be able to move this forward. Siri you're assigned to a couple reviews on here, do you know when you'd be able to get to it?
Siri: I've provided my input, but it's just placement of plus signs and things like that
MK: right now Jon is the only reviewer on here, if you could add an approving review if you're OK with that, that would be good
Siri: as I said, did we make a few tweaks to it, could we move the chevrons?
SH: since those aren't things changed in this PR, I think it'd be better to open a separate issue
Siri: I'll do that
MK: so Seth, you have a PR you want to add?
Seth: PR https://
MK: Fix broken links affecting redesign
ST: these were broken links that are being affected by how we're traversing the content and building structure from the existing respec doc, but this change will benefit people using the existing examples today
ST: Actually it looks like the build is passing, it looks like I mistook my blocked merge for a failed test
ST: I believe they all have to do with an incorrect link to a role and prop anchor or a link that's relative that has the wrong number of dir traversals
MK: so it's just a set of changes to hrefs?
ST: yes, every single line change is just a change to the href
JN: all in examples, not in the base doc?
ST: yes, that's correct
JN: I'm guessing the link checkers weren't checking the examples subdirectory
JN: not surprising to me
ST: we can open an issue for that as a followup too
MK: alright I"ll take care of this today
APG Home Page Redesign
MK: welcome back Isaac!
ID: today I wanted to talk a little about the vision and goals for the homepage
ID: I went through the minutes of a meeting from last year where this topic was discussed, and pulled out ideas from there that I'd like to go over
ID: I'm just going to go through the main things discussed there as ideas
ID: one of the main things was we want to move away from this wall of text format and focus on guiding folks that might be unfamiliar with APG rather than having it primarily for people who are experience, because they already know how to find those things
ID: so focusing on folks that are new to APG, content that explains how APG is related to ARIA, make it simple and welcoming
ID: have easy to use resources and info. A few example sites were React JS, Ember JS, that do a really good job with their homepages
ID: another idea was to have a section that shows the most used pattern, most visited pattern. More room for other types of research, maybe about landmark regions, stuff like that
ID: so an area to showcase popular areas of the APG
ID: maybe have that be a rotating set of popular resources
ID: the last idea was having a place where we can ask for help from the community, maybe if we're working on something where we want feedback
ID: so a place to try to get that sort of participation from the community
ID: I can also see that being a good place for announcements of any kind, like if we have a new design pattern
ID: so that's what I pulled from the minutes, I feel like I have a really good set of ideas to get started on a wireframe and proposal. I also want to have a chance to see if anyone else has anything else they want to share, or any other ideas
MK: Isaac do you have a idea about how long it will take to put together the first couple ideas for wireframes?
ID: this week and next week I want to try to have one proposal ready. Today and tomorrow I'll work on this, and next week I'll continue Mon/Tues. I think that should be enough to have a direction to share. I don't know if I'll have something ready by Tuesday, but maybe mid-next week where people can start providing feedback, and the following meeting we can have an item in the agenda to properly discuss it
MK: that sounds good
MK: for the very first homepage especially was the idea that we wouldn't make any new content. That it would exist by taking snippets of existing content, making cards like you did for other pieces of APG. One thing we don't want to have to do in the next few weeks is come up with new content that we don't have
ID: that's something I wanted to bring up: content and copyright
ID: because we won't be creating new content, I think we might need help with copyrighting for small things
ID: I think we have some good ideas for how things are going to look like, but at some point I think we might need someone who can help with tweaking that copy
ID: I was wondering if anyone here might be interested in helping a little with that
MK: for sure, copy is one of the things I focus on the most
MK: but if there's anyone else who would want to contribute
MK: a way to do this is we put together a design with proposed copy, then get feedback
ID: sounds good
ID: I'll get to work and share progress as soon as I have a solid direction, probably mid next week
ARIA APG 1.3 Annotations
MK: lets take the last 10 min on annotations
MK: there are 6 issues in progress in the next steps column of the annotations board
MK: there are still generic github issues here. Actually 4 relevant issues
MK: for the annotations, we need to decide what we're going to design, what are the things we need to create
MK: I think it's going to be what James talked about before, some sort of static page
<jamesn> https://
MK: trying to think which one of these issues -- we have suggestion, comment, details, is that it for roles?
MK: usually we want a realistic use case on an example page. So my first question is, do people have suggestions on what that would be?
MK: I don't think we want to recreate something like google docs
MK: what would be something semi-realistic?
JN: Aaron has a codepen with a bunch of examples of markup within it. It's not far off what I would consider a good thing
JN: it's markup for an online word processor semantic coverage
MK: so it is intended to be an edit field?
JN: yeah
JN: just with contenteditable, yeah. It's got some suggestions and comments below
JN: it's a good start for somebody looking at what to do for this
MK: so you are advocating that we should use the editor use case to start with
JN: I don't see why we wouldn't. As long as people aren't going to freak out that it's just using contenteditable for an editor
MK: I was a little concerned about the potential testing ramifications there, but if the testing is narrowly scoped
MK: do we know if screen readers even intended to support this markup in contenteditable? Is it supposed to work in contenteditable?
JN: I don't know, it probably should, right?
MK: yeah I guess. If that's a use case that we should experiment with, then that gives me a sense of a direction to go in
MK: is there anybody in a position to start working on it with Aaron's codepen?
MK: Jon, is that something you'd be willing to try?
SH: I think Jon had to leave
MK: I guess that'll be our first step there, find someone with bandwidth to work on coding it
MK: Sarah do you see any concerns with a contenteditable?
SH: no, that's what I was thinking would be a good example as well
JN: I think the example in the codepen can be simplified, it's covering way more than we need to cover
MK: what would you leave out, James?
JN: just too much stuff, the document is too long and has too many comments. It's just more than we need
MK: oh yeah, we want the example to be as brief as possible
JN: it includes epub roles too that we don't need to be including in this
JN: we should keep it very targeted. We can maybe have other things that have epub roles, but we should target it an not overreach
MK: we should have just the stuff in ARIA 1.3
JN: there are some things Aaron is relying on that aren't in 1.3, and I think it's fair to use those
JN: they're in dpub ARIA
MK: OK, that gives us a direction
MK: I'll try to capture it in one of the issues