Meeting minutes
<Github> https://
<Github> https://
<Github> https://
<Github> https://
<Github> https://
New TAG and public explainers (Janina)
janina: Started ripping out a lot of stuff, but then realised the Explainer could reasonably describe our overall plans, and indicate which are to be addressed later.
… So having an overall Explainer for the public may be good.
… What do people think? Do we need to focus module-by-module for the public Explainer? Or just tweak an overall Explainer as we add modules?
sharon: Understand what you are thinking; we've always had one public Explainer but three planned modules.
… If we have new modules, would we just keep updating the existing Explainer? Or add new ones?
janina: Harder to add new ones; easier to update the current one. Some details in the current Explainer are incorrect (i.e. number of planned modules), but we could re-phrase.
sharon: If we decide to keep one public Explainer right now, and later got to the point where we want to split it up, would there be anything to stop us?
MichaelC: There are procedural impacts, but nothing really stopping us.
janina: I could get it done quickly if it remains general. I had started completely re-writing to focus much more on symbols.
… Symbols are a major contribution, and I think we can emphasize that more in the existing Explainer.
sharon: We'll still have this to review on a separate branch?
janina: Yes.
matatk: Explainer can be an evergreen. TAG explainer will be more focused each time.
janina: ACK; not looked at TAG one yet. A big concern is the stats (finding the next billion users). NIH has some data.
… The primary use it accommodating people's inability to speak.
sharon: We're moving forward with the (public) Explainer as-is then.
janina: Yes.
CR updates for new spec focused only on symbols
sharon: I've pulled out everything but symbols and started a branch...
GitHub branch: https://
Here is a neat URL to preview the document itself for those of us without it checked-out locally: https://
matatk: No problem editing this as there is a Tag in github. Using githack to read the version Sharon has edited with just the symbols.
… , fine to start pull request now if desired and everyone can review.
Janina: are we cross ref registry spec?
sharon: Appendix A relating to exit criteria needs to be looked at in particular.
<Roy> https://
MichaelC: Roy's already prepared a draft of the registry doc. Not too early to point to it in an Editor's Note.
<janina> +1 to registry draft rather than Bliss PDF
sharon: In the explainer, or module?
MichaelC: Both
<Roy> https://
janina: And we have an agreed approach with Russell/Bliss (focus on a subset of the vocab to start with).
… (Michael contacted Russell on this last week)
MichaelC: Also working on setting up a regular call with Russell.
sharon: I'll add a note to this. As per last week, we're still calling this Content module.
janina: Yes, for now at least.
… Make sure to call it a "registry specification".
becky: The example has @data-purpose in it; should probably use the standard attribute
… (which we're not specifying yet).
becky: We can put street address per the HTML @autocomplete attr.
… Also minor nit: 'bar' maybe shouldn't be used as primary residence.
sharon: *agrees*
ARIA-related issues
matatk: Timers, and use case on buttons with icons and text which we didn't support. ARIA thought there was enough semantics. Selecting things based on their role. I have been working on that.
… , I will write some code, and see if it works for people.
… , got the impression we should look at ARIA from TAG perspective.
Janina: difference between ARIA action and our action.
… , our users won't be using the screen reader only
… , ie. parsing the AX tree
matatk: There is no such attribute ARIA action. there is a role of command is an abstract. aria-action as an action instead of us implementing it.
Janina: not sure it makes sense.
matatk: it is confusing, related topic on @rel. not sure how this fits into ARIA could ask them for clarification.
janina: Judy suggested having TAG do a guided review of this.
matatk: guided review more explanation, seems like we are going to have to have TAG review while we are in the room.
Sharon: who would schedule this?
janina: APA would schedule this.
sharon: Would it be helpful to have a centralized issue where we can track this info?
janina: I think we're still a little unclear as to what we're going to CR with; will be clearer what we want them to look at once we're clear as to what's in the CR.
CSS (i.e., media-queries)
matatk: we can use Media Queries to replace content, animated to non-animated, we can also remove it.
… , not sure what the difference would be to either replace or delete.
… , Media Queries are a nested structure. so could be a good fit. all thinking about what is critical to me and varying in context. Some disagreement even within COGA on this. some just can't handle except just the bare minimum, ie. critical, everything else we can get rid of. becomes subjective when you just want less of. We need to be mindful of the more extensible, would you need to come up with new Media queries, for this. We ma
y invite Andrew Kirkpatrick,
janina: I've been thinking on this too. Suggestion: depends on how much we have in the way of semantics being presented to us. If we get a resolution (wrt the debate in WCAG 3 right now) that controls are more critical than photos/images, and we can distinguish those
… we could simplify the page so that it's comprehensible. Probably not quite that clean, becuase some controls do different things.
… But we could potentially chunk up the page rather than have it all there as one big blob. I think there are ways to iterate through the complexity and let users choose on that.
matatk: Section elements could, being responsive could have some benefits here.
janina: How do we draw a line and get a concrete question we can ask CSSWG?
janina: Maybe we don't need to ask yet, but do need to know if we're asking for an adapt-* prefix.
sharon: Yes, as discussed, we have this thread in parallel so we're ready to ask about that when we come to CR.
Microformats (Matthew)
matatk: I wrote an email about this.
Email for background: https://
MichaelC: My recollection about microformats is that they have some critical accessibility barriers in that some uses of microformats break semantics by putting machine-readable data in human-readable attributes.
… I think we dropped it at that, and didn't document it. If we need to, perhaps we could, but don't think we need to spend a lot of time looking into it. I don't think it's a viable path.
janina: Did this relate to a formal objection?
MichaelC: Not sure. Microformats are not specified in HTML. They were widely used by the time we discussed it though.
janina: I think there was an issue with some exposing of machine-readable content via AT. Maybe not this.
sharon: Maybe we need to update the wiki?
matatk: agrees with Michael, developers tend to like them. we need to acknowledge that. Do you have anything we can link to, I can dig in to see if there is any a11y issues as a result of using this.
Requirements emerging from the work on WCAG3 (Janina)
janina: Some things being talked about strike me as could be handled neatly by us, via CSS or attributes. E.g. error handling: what happens when you hit the submit button and there are errors in the page. "Fix what's highlighted in red" - the person could be shown only the broken stuff.
… The other issue I already mentioned, wether images are informative or not.
… They're just two issues that are amenable to what we're talking about.
… Instead of having to make authoring guidance for WCAG, we could just point to Adapt.
sharon: That would be something to add in future?
janina: As part of @simplification.
matatk: I personally wouldn't like this as it would change the layout of the page with just the errors showing, but this could be used for certain people. This could be an excellent use case.
janina: perhaps tab / shift-tab to only show errors on the page.
matatk: this could be done now with a browser extension.