Meeting minutes
<matatk> Proposed agenda: w3c/
matatk: I have 4 topics, but overarching goal is to see how our groups can cooperate together. And perhaps AGWG as topics as well
rachael: [presents slides RE WCAG 3]
… we have multiple levels of maturity for WCAG 3 content; we have been moving content into the Developing level
… over the next few years, we'll be working through to Refining and Mature
… structure we've worked out: top-level guidelines, subdivision of foundational and supplemental requirements
… below requirements, informative documentation - how-tos (akin to WCAG 2 Understanding), with methods and tests
… sibling to requirements are assertions, corresponding to processes performed by entities/organizations
… assertions are for things that are repeatable, but not testable
… requirement structure is more granular than the SCs were in WCAG 2
… applicability and exceptions are separated from the requirement for clarity
… still working on a number of questions
… our goals (which will lead to the ask) are to create as easy of an access point, as plain-language as possible
… trying to cover more e.g. cognitive, low-vision needs
… [ gives example of an assertion for Plain language review ]
… all of that is coming in January, maybe late December. We will have what we think is pretty close to the complete set of requirements that we want to move forward with
… they will still be Developing, not finalized; we would like to know about gaps
… asking for additional comments on the tests - each requirement will have at least one test below it
… would also love feedback on the assertions, or if we seem to need more
janina: This sounds like a review we should undertake, so I'm just trying to scope it to know what we should tell APA. Wondering if we should meet on it after we read and have thoughts on our own
… maybe jointly discuss it in late January or Feburary? Matt what do you think?
matatk: Yes, and thank you Rachael for the overview
Rachael: I will say it is a lot, maybe we should give you until March to parse through it all
… we will be collecting a lot of commentary, we don't want you to try to rush through it
matatk: Things I've heard this week that seem interesting/encouraging are the assertions and tagging
kevin: just to reiterate what Rachael said, it's probably going to take longer than 3-4 weeks for you all to go through it. Worth having a really thorough review, taking a considered approach
… we're really looking forward to the depth of review you can bring
… the cadence we've been going at is about 2 publications a year; we'll probably stick to that
… if we've got early review feedback, we may try to get it into the first subsequent publication, but otherwise we can aim for the one after. We'd much rather people aim to do it thoroughly
janina: We should probably discuss whether we want to assign particular people to look at particular sections
matatk: First of all we'll form a committee to determine how we want to do the review. This is really good; we've been looking at our processes, and we've got some new people to review stuff
janina: They've caught things that I missed, so they're good
kevin: This is about bringing all you've got to this one, whereas the horizontal reviews will be coming at it from their own angle
janina: You're looking for fresh eyes
kevin: We're looking to take a step back, and having other people to do that is very useful
matatk: One of the aspects of reviewing something is to identify what's missing, what's not there that we expected to see, but I imagine there will have been some balancing you've done with respect to whether something is a normative requirement or an assertion
… and there will be other places where you made trade-offs
… I'm wondering, is there a consistent way for us to get to documentation about trade-offs and decisions made?
… e.g. why we decided to do / not do things
Rachael: We won't have a schema for every single requirement and assertion, but we can easily put together a wiki on what the general rules are in making the determination
… we'd been writing it, but hadn't thought about providing it to reviewers, so that's a good point
Ken: Source documents have many data that could be used in terms of thought process
kevin: yeah, I would probably not dump the whole lot on you, but there are some things that may be worth looking in the scratchpads for
… and if you're coming up with those kind of questions, then the rational probably needs to be surfaced more clearly in the document itself, so the fact you're asking the question could lead to a change
Rachael: I don't want to commit in advance to pulling all of that together, but to kevin's point, we can research in response to questions
Updates from APA
Discoverable Destinations
<matatk> https://
matatk: This is something the APA has been doing, but what the Adapt TF has been doing is making this usable by COGA
<Rachael> For anyone not familiar with it: https://
matatk: it should be possible to make automated or semi-automated robust versions of the documentation if we had a bit more metadata
… that's an objective of the Adapt TF
… not limited to cognitive accessibility, but rather everyone can suffer from these disabilities, e.g. tiredness, non-native-language, being busy
… there's a number of really common things you might want to do on a site, e.g. log in, search, get help, see the accessibility statement
… what we are seeking to do is come up with some tokens that can be used to signal those destinations
… those tokens aren't meant to be rendered directly, they can be rendered to the user however they want
… using existing HTML idioms, i.e. the link (not anchor) element, it will share common discoverable destinations on the site
… so as you browse, your UA will discover these destinations are available
… so it doesn't matter what the site calls it, it is presented in the term that the user understands
… we had a realization last TPAC that there is already sufficient standard infrastructure to do this; the only thing we really need to do is settle on what the standard destinations are
… we have a browser extension that will surface those, but ultimately it could be inside the browser or any extension
… the other thing that's become apparent recently is that this way of navigating is designed for people, but it will probably benefit machines/agents as well
… we had a breakout earlier in the week, I believe it was recorded as well
janina: We should probably think about it and have a conversation as to how we want to develop this list of tokens. We probably want to start with a short list. I imagine log in will be on it as it's extremely common
… accessibility-statement might be on it
… it's going to be socialization that makes this work
… since it works within existing areas of HTML, though they may be currently underused
… we need to be careful about what we choose, but we can start choosing
… and it shouldn't just be APA that chooses, we should involve wider community, and AGWG seems like a good place to start
matatk: That's true, we need wide buy-in and need to seek input
… it might not be standardized in the W3C sense, it might be organic, but we might want to lay out a minimal set
… maybe a helpful analogy: think landmark region, but for the whole site rather than one page
kevin: There's 2 things to this; it's not purely an accessibility thing. If you look at MDN, search is something that's already using the rel attribute
… one thing I'm thinking is, do we need to line this up with other areas e.g. security and privacy to create a token list that's more-encompassing / more broad?
… I wonder whether or not we want to look at some user research to understand what users actually want, and a broad context might again be the way to go with that (though I hate to suggest something that adds more work)
… maybe come up with ways to render the material tailored for the person
matatk: to provide reassurance, we are aware of some similar things in areas like security, but folks in those areas advised us to take this on separately
… RE user research: COGA research, and input from someone who has joined recently RE accessibility statement
… would like to involve user research in wide review, but would also like to experiment with different UIs
… we imagine that if this goes into browsers the UI will be minimal; may still want to do more with extensions
Rachael: I do think the accessibility statement becomes more important as we build assertions into WCAG 3, so that's an interesting intersection point to talk about
… talking about requirements and support in this being integrated is really important
… RE COGA, wondering if you're thinking about tagging content based on importance, or providing different importance levels to different types of content, or is that just not on the table at this point?
matatk: We could potentially decide different ways to do this in the future if folks decide we need to
… RE flagging importance of content, that's something that's currently out of scope but we've been thinking about it for some time. Really difficult to solve because what's important depends on many contextual factors
… it's not necessarily something that can be authored in, although from the COGA perspective they are talking about a more cut-and-dry version, i.e. what is absolutely essential, and that may be slightly easier to do from an authorizing perspective, and we are interested in thinking about it, but it would probably be separate from this
<Zakim> mbgower, you wanted to say reducing and enhancing inference
<mbgower> https://
mbgower: It's interesting to see where this is going, compared to previous unrelated efforts a few years ago at CSUN that relied on custom attributes
… what I've been hearing this week that seems interesting, in one of the AI discussions earlier in the week, they were once again trying to leverage a bunch of ARIA attributes to reduce the inference error rate coming out of AI.
… I think what you're settling on now is so much more contained
… how to ensure that people are effectively labeling buttons and UI components properly so that the name of them made sense
… e.g. converting text to meaningful symbols
… can we come up with a controlled vocabulary, do a scan of many pages, come up with a set of commonly-used terms used for buttons/links, figure out synonyms
… create a tool that checks for unrecognized labels, to prompt authors to attach to a known action
<mgifford2> mbgower it does seem that the Web Almanac could help with that.
mbgower: the more we can infer what authors mean, the more we can unpack programmatically
matatk: That's awesome, great to see you again, I remember that document, please join ADAPT and come and help
janina: I love that we're talking qualitatively. We're trying to be extremely simple in providing a mechanism.
<mbgower> I worry about the value of that accessibility statement after the lawyers get hold of it.
janina: we can support a machine-readable version.
<mbgower> I think importance can be very valuable in specific use cases. The importance of an image, from an author perspective, for example.
<Zakim> JeroenH, you wanted to comment on accessibility statements in Europe
JeroenH: RE accessibility statement, in EN 301 549, it's mandatory for all government organizations in Europe to provide an accessibility statement
janina: We're just trying to socialize where/how you make it discoverable
matatk: We're also working to make ours machine-readable, which an accessibility statement page might not be
JeroenH: We're also making ours machine-readable.
kenneth: RE mbgower, sounds like the opposite extreme - someone previously said, we're expecting users to be reasonable.
kenneth: Appreciate the minimum viable subset to start with.
AAC Symbols on the Web
matatk: We're still working on the symbols thing as well. It's a bit different; I'll share a couple of examples so that if you're a visual person you can see
matatk: [displays example] This is some text containing symbols with each chapter title
… this uses a particular symbol set called Briss, which is actually a language that's symbolic. We used it because it has a great variety of symbols and concepts
… [displays another example] This is the same content, with a different symbol set called ARASAAC, much more colorful and pictorial rather than symbolic and schematic
… this is just a demo, but how it will work is we have a registry based on concepts that Bliss knows, because Bliss is the superset
… the idea is, the web content author puts something in the document that indicates the concept, and that gets mapped to the symbols the user wants
… we think we're close to an implementation, but it isn't decided yet, we have a meeting later to discuss how successful that approach might be
… but goal would be for the author to specify the concept
giacomo-petri: Potentially this kind of implementation could help in addressing the SC about identifying input purpose
… there is always this concern about security and accessibility about providing the autocomplete attribute
… could this potentially solve the problem by not requiring the autocomplete attribute, and providing an alternative representation of the written language?
matatk: That's an interesting idea.
… We've had another topic around input controls, and autocomplete tends to convey information
… you could potentially make it serviceable just based on the symbol that the user understands
… once this approach is in use, we expect it will be based on the existing technical stack of fonts to do the mapping
… if we do that we could potentially make it work for autocomplete as well
kenneth: Specifically as you mentioned fonts, icon fonts can be very bad for accessibility - not doing that?
matatk: Nope, don't worry
Pronunciation
Explainer: https://
Mattatk: We have another TF, Spoke nPronunciation of Text to Speech
Use cases: https://
Mattatk: Working on it for a while, serves the needs of educators and people doing assessments
… There are sill SSML, some CSS approaches, etc
… We worked on something earlier. Not a viable approach
… We have rebooted the Task Force. Mainly long-hanging fruits at the moment
… Industry effort. Based on data- atributes
… They are finding some value in solving these problems
… We've had meetings with other groups. There are other use cases, for example bilingual books
… The voice changes completely between languages, it makes it a bad user experience when there are different languages in the same paragraph for example
… Depending on how it goes we may ask AGWG how this could be part of WCAG
<mbgower> Matt, do you have anyone from epub on that? I'm not recognizing any names.
Mattatk: Please read the explainer and use cases
Janina: There is a smart voice agent workshop scheduled by the end of February
… Proposals due by the end of November
… AI agents are speaking up, not just AT
… I wonder if the landscape is changing
W3C Workshop on Smart Voice Agents: https://
Kevin: I think voice agents and voice interaction is a massive use case for interaction, agentic AI is driving that, but we've had this for a while with voice agents interpreting web content for some users
<Zakim> kenneth, you wanted to offer to resume scribing
<Zakim> mbgower, you wanted to say it also involves recognition too
mbgower: RE what Kevin was just saying, I don't think it's just a problem on pronunciation too
… another thing is recognition of e.g. proper names
… e.g. Siri consistently mispronounces variant of Jonathan, and I have no way to correct it
<mgifford2> Would be so good to have Google Maps not mangle street addresses (especially in a multi-lingual street name).
mbgower: at least with e.g. JAWS you can control how the pronunciation goes there
… in this ecosystem we'd want to be able to control what's coming in, but also support unique words, "mispronunciations" based on locale, etc.
… think it goes both ways, not just pronouncing to the user
<Zakim> daniel-mac, you wanted to say not just JAWS
daniel-mac: Most screen readers have this built in, not just JAWs
matatk: Fun example, from education: I had no idea about this, but pronunciation of words can change even within a few generations
… if you listen to British news broadcasts from 1920, they pronounce "combat" differently when referring to wars
… usually TTS gets it right, but there will always be outliers
<mbgower> It can even change for the same user based on the context on the work they're doing. Especially for acronyms.
matatk: don't want to overburden the author too much, but we'll need to sort it out
<Zakim> matatk, you wanted to give an example
daniel-mac: whatever we end up with, we should be really careful that it won't have an impact on what AT either needs to do or has to do
… users of AT want to be in control of what AT is pronouncing
Framework for Accessible Specification of Technologies (FAST) (FAST TF)
matatk: The FAST TF is another TF within APA (and formerly AGWG)
… there was a breakout earlier this week
https://
matatk: going through in broad strokes: about the resources for spec authors that we have and are working on RE getting review, so you don't need to do as much work to do when the review gets done
… we link to all these resources on the WAI site, and ones that we are developing
… the TAG has an accessibility screener that is between 5 and 7 questions, really high-level
… the result of that, a really easy-to-use HTML form, is a github issue that the spec group (WG or CG) can have in their repository and link to it so we can see the answers to the questions
… the point of these high-level questions is to get in broad-strokes terms how much accessibility work is needed
… being an HTML form now makes it much easier
… you may have heard of or used the FAST checklist which was a more in-depth but similar thing
… links to relevant WCAG SC
… was cumbersome for people to fill in, because we didn't provide a way to fill it in. People ended up going off and providing their own templates
… there is now a HTML form for them to fill in
… because the FAST checklist is more detailed, we create a github issue where they can check things off as they do them
… that's a thing they can do for horizontal review which typically involves more details (though it often comes too late, which was the subject of another breakout)
… this can be done in the repository of the spec so it can all be in the same place, owned by the authors
… what's actually needed are use cases
… we also have technical expertise in some areas, and we know people in other groups with expertise, and are working with these people and keeping track on who knows about what
… a resource that people can go to before review to know what sorts of things they need to consider, to ensure that things built with the spec can be accessible
… we have a matrix of what we call user needs, i.e. what do you try to need, e.g. understand the purpose of a control
… and functional needs, which are about barriers you might face
… one of the complaints we've had from spec authors is how we're presenting information to them is too general; they need more concrete, web-focused examples
… because there are other projects looking at this stuff, we're re-focusing FAST on being concrete and specific
… what does the author have to provide to the AT, to the user
… that guidance is being reformed and will be presented as a resource alongside things like the digital accessibility user requirements documents from RQTF and COGA
… that give you a whole range of use cases and technologies
… the accessibility user requirements (AURs) are for specific media types
… application-level things that build on top of WCAG within a specific application domain so they can be more concrete
… really build on the experience we've amassed over decades
… it will be for spec authors, will lean on WCAG, will be about pre-empting the sorts of issues, so that we don't have to come along and say things like, "you know, your spec should really have a way to provide alternative content for these images"
… not going to constrain things too much, but going to be much more focused on spec authors' needs
<Zakim> kevin, you wanted to ask if we can change the name?
kevin: It sounds like we're dumping the FAST draft note, the big long list of functional requirements, it sounds like that's not the focus of FAST any longer? which I have no problem with
… but we talk about FAST and FAST checklist, and I'm wondering if we can make it more "it does what it says on the tin"
… and make it the @@ accessibility checklist
matatk: TAG has an accessibility screener, which is super high-level, super-quick.
… the FAST checklist is a big checklist, which is bigger and heavier
… still being developed within APA for later on in the process, is still useful
… we will continue to develop it and make it more suitable to spec authors
<hdv> +1 to a name that more clearly describes the thing
matatk: the branding, if you will, is you've got the screener that you start with, and the checklist that you do later on
<hdv> accessibility checklist, accessibility screener?
matatk: sure we can change the names, but that's the idea, something you do early, and another thing you do later
… right now, TAG does the screener, APA does the checklist
kevin: I'm happy with all of that. I think it's just trying to describe more effectively with the name. I think we're hiding what it's doing right now
matatk: There still will be a document called "the FAST"
… we're still building it, but with a focus not in the general sense
<Zakim> mbgower, you wanted to say I had some questions about human language in your speech section
matatk: user needs and functional needs - that document will change significantly, but there will be a distillation of that document that will be the checklist, and the checklist will refer to the document and to WCAG
<shawn> [ The FAST checklist then the WCAG Quick Reference... ]
mbgower: Maybe this is no longer relevant given what you were just saying, but going back to the 2024 ED and something Kevin said, I find myself more and more giving feedback on speech interaction
… there's a very small amount of speech in the document. It fails to distinguish between language and what we call human language
… i.e. distinguishing between "French" or "English", and parts of language
… I would really encourage specifying which of the two is being discsussed
… I'd advocate putting much of what you shoved into language & communication also into speech, or make cross-links
hdv: Quick +1 to kevin's concern. I know what FAST is because I'm in this room, but most of TPAC isn't in this room, and will have to go through this checklist and the screener
… I think a clearer name will benefit those going through the process
matatk: Absolutely, and we want to encourage people to engage the process early
… thank you to everyone for the really helpful input
<Zakim> mbgower, you wanted to say thanks to the organizers
<kevin> [ Specification Litmus test Of W3C (SLOW) ]
<mgifford2> The tech support has been amazing here too!
<matatk> +1 to mbgower; great set-up; makes us feel more together, een remote participants
mbgower: Also thank you to everyone (mostly not in the room) who have made all of the cameras and sound and calendars etc. work