Meeting minutes
Setup and Review Agenda
Matt_King: Next meeting: August 13
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Publication planning
Matt_King: Howard made a pull request to publish 5 other pull requests
Matt_King: I'm tentatively suggesting September 9th as the due date for next publication
Matt_King: That will make it viable to share at TPAC
dmontalvo: That should work
howard-e: That's fine for me, as well
Matt_King: Alright, we'll set that as our target
Matt_King: I think there's one pull request that I already merged for that
Matt_King: It was a straightforward editorial correction
Matt_King: I'm working on one related to the use of the "kbd" tag
Matt_King: There's also one about jongund's work with high contrast
Matt_King: And work on sortable tables that ariellagilmore is working on
Matt_King: So, we have a start on the next publication
Matt_King: And we'll probably add more to the milestone later
Code guide updates
OliverH: I reviewed the code guides that we referenced at our previous meeting
OliverH: I tried to match the assumptions in the thread with the content in those guides, and I gave recommendations for each
github: w3c/
Matt_King: I think I would like to move the content of the guide guide out of the wiki because we can't submit pull requests against the wiki
Matt_King: We do have a place in the APG for information like this
<jongund> https://
Matt_King: If I created a "shell" page for this, would you be willing to draft a patch that relocates the content?
OliverH: Sure
OliverH: I'll plan to submit this with one commit that simply relocates the information and a separate commit that proposes changes so that it's easier to understand the modifications we're considering
Matt_King: That sounds great!
Long term plans for HTML examples
github: w3c/
Matt_King: There are a couple of things we'd have to work out if we were going to start building native HTML examples that are equivalent to the current examples but that essentially avoid using ARIA as much as possible
Matt_King: That doesn't necessarily mean "zero" ARIA, but it means minimal ARIA and JavaScript
Matt_King: Some of them may end up being trivial. For the button, for example, it might not even be worth having a dedicated page at all
Matt_King: We definitely want to do this over time; this is part of our expanded mission
Matt_King: But what's the best way to fit it into the APG in a consistent manner?
Matt_King: Do we just want separate examples? Or do we want additional sections in the existing examples?
jongund: We generally want people to use native semantics.
jongund: A lot of people use "link" elements to create things that act like buttons.
jongund: We do it ourselves in two examples, but neither of them are something I think we want to promote. You should be using "button" elements
jongund: For us, I think we need more explanation about that
Matt_King: We do that to some extent. In the menu bar pattern, we say "the disclosure is the simpler pattern; only use menu bar if the following things are true [...]"
Matt_King: So we can steer people from one pattern to another. That part, we kind of already know how to do
Matt_King: We can follow that exact same kind of pattern--we have quite a few places where we definitely want to separate content, already
Matt_King: Across the board, it's better when we have exactly one example per page. Right now, though, we have three examples for the button. Separating them out would make this easier
Matt_King: We don't have that problem for disclosure, though, so starting out with disclosure might be easier, since it's already a separate page
Matt_King: That's one way we could do things at the level of the examples, but I'm kind of wondering if there's a way we can address this at the level of the patterns
Matt_King: We currently list two sets of requirements: keyboard requirements and role-stated requirements
Matt_King: Those are making assumptions, but they aren't maximizing the use of ARIA--that's for sure
Matt_King: If were were adding information about how to minimize the use of ARIA, it seems like we'd have to do that on all the pattern pages... And we'd want to do that in a really consistent way
jongund: It's a tough problem, architecturally at least
jongund: In general, we want to promote native semantics for HTML. But using native semantics doesn't necessarily mean you wouldn't use ARIA at all
jongund: It's not a question of "all ARIA or no ARIA"
jongund: What's the relationship between APG and the developing WAI tutorials?
Matt_King: We might just link to those tutorials
Matt_King: Maybe there isn't a single treatment for this topic; maybe it does need to be decided on a pattern-by-pattern basis
Matt_King: For some (like summary details and disclosure), we might just add a note to the examples which direct readers to the preferred approach...
Matt_King: I don't think we'll be doing this overnight; I think we'll do it bit-by-bit with tiny pull requests
Matt_King: Maybe someone should set up a project to review all of the patterns and decide how we'll approach this
jongund: Should we just start with disclosure since that's what this issue is about?
Matt_King: Well, there's some value in thinking about this holistically before moving in any particular direction so that we know we're approaching a complete solution
Matt_King: I don't know where this sits in the big picture of our overall roadmap
Matt_King: We're also considering refactoring the landmark examples, for instance
Matt_King: I think we need someone who has plenty of time and is ready to spend several months on it
jongund: It seems like at least for the disclosure, we could at least create an example that uses details-summary and show that you don't need to explicitly add these attributes and manage them
<OliverH5> Sorry but my connection keeps dropping out and I can barely hear full sentences, neither can I see the shared screen :/
Matt_King: We'd need a different kind of editorial copy in the example page, but we could work that out
Design keyboard interface for tabs with action buttons
github: w3c/
Matt_King: Adam Page will be joining the meeting next week, and I think he has volunteered to take this one one
Matt_King: It will be our first experimental example. It's very simple
Matt_King: Most of the authoring requirements for aria-actions are pretty straightfoward
Matt_King: One of them, though, opens a lot of questions
Matt_King: It's about the way actions are focusable
Matt_King: There are a couple ways of doing that
Matt_King: I just started brainstorming and made a list of ideas; they're available in my most recent comment on the issue
Matt_King: I don't know if there are any conventions here
CurtBellew: I don't know if we have any of these in my product
Matt_King: I know of an implementation that I don't like...
dmontalvo: I think I would prefer the first of the six points you have listed here
dmontalvo: Though, as you note, the arrow keys depend on the orientation of the tab strip
Matt_King: Option 4 might work better with a vertical tab strip, and option 1 or 2 might work better with a horizontal tab strip...
jongund: I'd like to think about this some more
CurtBellew: I'd like to think on it more, too
jugglinmike: With vertical tab lists, I wonder if the direction of the "open" action should be informed by the document's language. Maybe it makes more sense for the "left" arrow to open a menu that's presented in a left-to-right language
Matt_King: That's an interesting thought and worth considering
Matt_King: ...but we're out of time. Thanks, everyone!