Meeting Minutes
Charles Hall: I'm I'm looking at the Respec doc for the first time.
Ned Zimmerman: Okay, great
Mitchell Evan: Is there
a specific section for a question that for for the conference.
Ned Zimmerman: Sorry, Mitchell, I lost the latter part of what you said there.
Mitchell Evan: Sure.
Is there a specific question or section that —.
Ned Zimmerman: I think this is the
sort of structured document that Wendy put together since the last meeting, so I think the whole thing is up for discussion.
I think we could talk about I mean, maybe a good way to look at it would be to start with the high-level structure and see what people think of that, and then we could go through it.
piece by piece.
If that sounds good to people, I'm open to other proposals too if other people have different ways they'd like to approach it.
So
Jutta Treviranus: I wonder whether, given that many of the standard use cases we've gone through, whether, we should look at some of the newer use cases that are brought about by AI, like,
Jutta Treviranus: agent editing or some of the assistive technology alternative interface strategies that are being created.
Ned Zimmerman: Yeah, so you're thinking adding additional focus on those aspects in this document, Jutta?
Jutta Treviranus: Yeah, or — yeah.
Ned Zimmerman: Yep.
Jutta Treviranus: Because, yeah, to look at what is now different in terms of the use cases and roles, given that we now have AI in the mix.
Charles Hall: If we wanted to, stick with the structure.
Question first. The first thing that I observe is the numbering scheme.
gets broken after the paragraph.
So the each like two dot one dot one, for example, has.
Ned Zimmerman: Oh, yeah.
Charles Hall: starts
the items that have ordered lists, but the ordered list then starts new versus 2.1.1.1.
Ned Zimmerman: Right.
That's all.
Mitchell Evan: I'll try my audio. I also have a voice disability, so sometimes I type my answers. Let me know if that's helpful.
Ned Zimmerman: It's coming through on the transcript pretty well, and I can hear you reasonably well, yeah.
Mitchell Evan: Okay. My comment was,
Not having that too much trouble.
My first impression is that.
There's not
In the real world, there's not that much difference between content creation and content modification.
For example, if I create an empty document that has the words "Hello World," now everything I would do is modify that document.
You know, it's the same as creating a document new, so it's something to look at in the structure to see if those could be merged or
Ned Zimmerman: Right.
Mitchell Evan: Perhaps there's only a small delta for modification that's not part of creation.
Ned Zimmerman: Mmhm.
Right, so I think that drawing that distinction between
Adding, changing adding to or changing existing content, and
other more, like, transformative things, like exporting content to different formats, maybe?
I think there's also maybe workflow considerations there, though, because the thing that jumps out to me about
Some of the, parts under content modification.
is that there are sort of additional layers to the content that are being worked with here, whether that's, you know, annotation or adding metadata as opposed to modifying the content itself directly. But I think that is definitely a distinction worth.
We're teasing out a bit more. So thanks for that.
Mitchell Evan: yeah, so, and oh, I'll just finish by saying that. There may well be
reason to have the separate sections. But to me, for example, adding accessibility metadata to content.
It is something that I would do. Hello, Word documents that I just created. I don't see a distinction between creation and modification, adding metadata to a document, for example.
Ned Zimmerman: Right.
Mitchell Evan: That's it. Just an example. Thanks.
Ned Zimmerman: Perfect, thank you.
Miriam, I'll just drop the link in. We're looking at the use case requirements draft that Wendy shared. I realized I didn't get screen sharing permissions from Wendy for chairing today. So unfortunately, I can't share my screen with the document, but that's what we're talking about.
So just a comment from Charles in the chat. Creation occurs once in any workflow. Modification occurs in nearly all workflows. Do you want to expand on that at all, Charles?
Charles Hall: Just agreeing with the observation that Mitchell shared.
Having the document organized, by
this phase.
of content.
is
an opportunity for redundancy. There will be overlap between those two categories, so we need to find a way to eliminate the overlap.
Ned Zimmerman: Is there anything in this document that seems to be missing, you know, that's jumping out at people as being missing from our earlier discussions?
That should be there.
in any of the sections.
Charles Hall: I don't know about, use cases or rules or phases to answer that question. I haven't fully digested all of this, but,
from a document
standpoint, and something that we will absolutely need in here is a glossary.
One of the things that I see, for example, is the use of the word validation.
and and validation has specific meaning in in a couple of different contexts here, and I don't think that's what we mean. I think we mean evaluation.
Ned Zimmerman: Right, yeah, that's a good point.
I'm going to create a new tab in the Google Doc. And again, I'll just drop the Google Doc link in here.
This may be — actually, maybe we don't need a —.
a new, tab here. under things to research and define, I think to that, comment, Charles, I'll put in a heading, for glossary terms for
for this document, and we can just drop anything in there that we think.
that people think is the
Charles Hall: Yeah, we
Ned Zimmerman: needs to be in that glossary.
Charles Hall: We, being a community group serving as the incubator, we don't need to have.
formalized definitions for things, and we don't need to try and define anything whose definition already exists in another resource like ATAG or WCAG.
But things that we're using or introducing in this document, we should absolutely have.
Ned Zimmerman: Yeah.
Yeah, for sure.
Mitchell Evan: I'm going to plug in a couple of comments. And no particular order of these comments. One thing that I think, I personally think is one of the most important.
Parts.
Offering full accessibility is.
prompting users.
to create accessible content.
I don't remember exactly which port Statewide is currently back to.
I know that.
Section 508 says, "Often tools must prompt users for accessible content.
EN301549 goes.
I'm seeing less back here. There's only one sub bullet.
that said something like.
Should be able
Oh, I just got it.
Ned Zimmerman: Is it
3.2, the fourth one, the authoring tool must be able to inform the user of which inputs are required. Yeah.
Mitchell Evan: Yeah. Yeah.
Yeah, it's,
I think that needs to be more
prominent and more fleshed out.
Ned Zimmerman: That's a really good point.
Mitchell Evan: There's plenty of allowed users to do it, but not enough prompts.
Ned Zimmerman: Yes.
Yeah, and we discussed, I think this may have been before you joined the group meetings, Mitchell, but we had discussed.
the challenge of the word prompt now having taken on a bit of a different meaning in the generative AI or large language model context, and and the need to think of a different way of expressing that that's not gonna
Ned Zimmerman: make that ambiguous between those two two senses. but I take your point, it's a very good point, that there needs to be more about the
guidance from the tool itself to the author, the guidance that the tool provides to the author.
And yeah, we can definitely look at
Extending that in that section.
Jutta Treviranus: And in some cases, it's more than guidance, it's influencing because there's both the intent or the motive and then the ability to.
Ned Zimmerman: Yeah.
Miriam
Miriam Fukushima: Yeah, and just to add to that, before Mitchell joined, we went through the sections of ATAG, and I think there is a thread in GitHub for that.
where we extended all the, points where we're saying, okay, here, something needs to be added or changed, or maybe divided into different sections, or whatever. so, yeah, if
You also have some stuff for that. Then.
I don't have the link for the thread at the moment, but maybe we can look it up.
Ned Zimmerman: I'm looking for that one. Is it the changes from ATAG 2 thread, do you think, or
Miriam Fukushima: I think so. Because I think it's good to have that in one place.
Ned Zimmerman: Oh, no, that's actually a very short one.
Miriam Fukushima: I think it's ATAG 2.0 for areas needing extension revision.
Ned Zimmerman: If you have a link to that that you could — OK, great.
Miriam Fukushima: Maybe that one.
Ned Zimmerman: Oh, in the wiki. Ah, perfect. Okay. I was looking in the discussions. That's great. Thank you for dropping that in, Miriam.
Miriam Fukushima: Yep.
So because we have been concentrating on the use cases a lot lately, but yeah, so that if we have points for extending or like correcting ATAG as it is that it. All goes in one place.
And not another tab in the use case document.
Ned Zimmerman: Yeah.
No, that's great. Thanks for sharing that.
Jutta Treviranus: I wonder whether provisionally we could add a category of new roles and tasks or.
Something that extends beyond.
What we previously had been looking at in terms of actions and user requirements.
Ned Zimmerman: Can you expand on that a little bit? You said new roles and tasks in the context of this document, of this draft or?
Jutta Treviranus: Well, not necessarily formally going into that draft, but just to brainstorm, what are the additional things we need to contend with in this changed authoring environment that we're in at the moment?
to then be evaluated whether it actually deserves a new category or not.
Ned Zimmerman: Right.
Are you thinking of this beyond what we had discussed in the Google document in terms of the ATAG feature use cases and requirements, the user needs?
and requirements there, like things that we haven't covered there, or
Jutta Treviranus: Well, I think there's there's a area for discussion where we haven't actually.
resolve things where we are actually moving into more of a user agent space, and that given the the vacuum of user agent work at the moment. Are there things that we need to sort out? What is authoring? And given
the opportunity to for an author to author user agent functions, etc. how do how do we address that within this document?
Ned Zimmerman: Right.
Jutta Treviranus: And apologies, everybody, I'm sort of multitasking, I'm I'm actually on a panel, so, hence not raising my hand before I speak, and I apologize for that.
And I'm actually in another meeting as well.
Ned Zimmerman: Yes, Miriam, go ahead.
Miriam Fukushima: just
Oh, one sec.
Bye.
I need to recline a call too.
I was wondering if Jutta meant something like in the tab things to research, define authoring tool types and functions.
If that goes in that direction or not.
Ned Zimmerman: Yeah, that could be.
Yeah, I see that comment, Charles.
So just Charles in the chat says, 2.1.2, using the language's accessibility features, should explicitly name accessibility APIs, which is the consumer of the technical content, like MSAA, UI automation.
IA accessible to UI accessibility, NS accessibility, and any forthcoming APIs and versions. Thanks. That's a good point, Charles. Mitchell.
Mitchell Evan: yeah.
One I I
Remember, from our first conversation — my first conversation here last week. And I'm seeing the calendar.
No, we don't have to,
You know, formally find a tournament to find elsewhere.
I think, what? What is the authoring tool?
is kind of critical. There's a little bit about it, but there's at least one question not answered is.
Do we consider an author?
to something that creates content just for use by others.
creation of content for one
Ned Zimmerman: Mmhm.
That's it.
Mitchell Evan: I believe it's a difference between these standards at the moment.
Ned Zimmerman: So the difference between creating content that's only consumed by oneself versus is for broader consumption, just to make sure I got what you're saying? Yeah.
Mitchell Evan: Yeah, that's correct.
Ned Zimmerman: Okay.
Yeah, that's an interesting distinction.
Mitchell Evan: Like a like a note taker.
Like I'm making notes for myself, but no sharing option.
Ned Zimmerman: Right.
Mitchell Evan: That's an example of something that's not an authoring tool. If I'm not mistaken, ATAG 2.0 would say yes.
But Section 508 and the European Standard would say no.
Ned Zimmerman: Right.
OK, that's very interesting. I wasn't aware of that.
Miriam.
Miriam Fukushima: Yeah, I think what we discussed so far for that point was that we mainly make the distinction that we don't include everything that is coded.
in general. But for example, if I make a myself an app where I can take notes or something versus when I put that app onto the app store. Then it becomes relevant for Atag.
but that we also prioritize like big tools versus not every private person that can put something on the app store. But like, if you put something as a company or.
even if it's just one person company, but like as an official person on the Internet and distributed, then it becomes relevant for Atag, and of course, then.
the more widely used your tool is, the more relevant ATAG becomes. But we also, on the other hand, distinguished like the different kinds of authoring, like not only authoring content that can then be consumed, but also like developing, is also.
authoring content, even if it's creating another authoring tool. And also, that in itself, an authoring tool can have multiple different versions or be a platform of multiple tools.
that has, especially also with AI coming in, where you have different kinds of interfaces that in itself could also be authoring tools.
And yeah, those 2 discussions we had.
If that helps.
Mitchell Evan: I think all of those points are relevant to a kind of introduction that says, when we say authoring tool, what are we talking about? Funnily, though, I don't think it actually addressed specific questions.
An aspect of that that I was raising is not whether the tool is available on App Store, but whether the content I create with that tool is shareable with others.
Like, there's no sharing function.
So yes to all of that, plus my question still fits in there. We don't have to answer it all right now. I think it all points to this document should.
Be pretty explicit about
What is and it's not a lot of control.
That's far for this purpose.
Miriam Fukushima: Yep.
What I think is what we shouldn't forget is if the tool in itself has the responsibility to share. Even if I use it for my personal use, like, for example, if I put a create a PDF in Adobe, and it's for my personal use, that's all fine, and I can do it as crappy and dirty as I want.
But still, Adobe has responsibility and as an authoring tool, Adobe needs to be evaluated and should adhere to ATAG independent of who uses it and for what purpose.
Because it has the capability to be an official tool.
Ned Zimmerman: That makes sense.
Jennifer?
Jennifer Bullard: Thank you. Yeah, I mean, I think this conversation around what is the tool intended, like what is authoring is really interesting because I think of my notes
On my phone, my notes application, I use that a lot, just for personal things. Now, would something like that be beholden or required to adhere to these
To these requirements.
So I'm sort of thinking about that, because, like, the minute I share a note with somebody else, then these requirements become a lot more important.
Jennifer Bullard: but my my comment was actually about, Section 3.1, Authoring Tool Accessibility. Number 2 says the authoring tool supports use with different assistive technologies.
and I'm just wondering if it's worth calling out here which assistive technologies, like, what
we're talking about, you know, because I think when when people, you know, out when people outside of, like, the accessibility community talk about assistive technologies, they don't really know what, what we're talking about, and screen readers is maybe the most common example, but I think that there are a lot of different.
You know, technologies that we could be calling attention to.
Ned Zimmerman: Mmhm.
I think that might be one of the things where, as Charles said, there's definitions and documentation for many of these terms in existing W3C work that we could link to there just to make that explicit.
That's a good point. Miriam.
Jennifer Bullard: Yeah, I think that would be great.
Miriam Fukushima: Yeah, to that point, I think we also discussed that this time in ATAG, we also want to create additional materials and resources to better accompany ATAG.
so I think that would be a good way, similar to the use cases, to kind of,
explain a bit better how different scenarios could look like, or different assistive technologies could look like in the realm of authoring tools.
That was one point, and the other one was
Regarding the notes app example, I think.
It's also important to not forget just because I don't need certain accessibility features when I write my notes.
It doesn't mean that a different user doesn't need those accessibility features, either in creating notes, while creating the note in the authoring tool, or for later reading and consuming one's own notes. So that's why I think the distinguishing between do I share it, or do I use it myself is not as important as.
the responsibility of the tool itself and the distribution.
Mitchell Evan: I agree with exactly what Miriam just said.
And I think that's what ATAG should say.
creating content for one's own use should be in scope.
And we might even want to point out that that goes beyond what —.
But US and European standard currently.
That's a good thing.
Ned Zimmerman: Yep.
just in the chat, Ellen had to drop off, and Charles went to the current definition of assistive technology from WCAG 2.2, which is great.
Just to speak to that comment from Jennifer.
Any other thoughts so far?
Charles Hall: I just jumped to the WCAG 3 glossary to see if we had updated that definition, and if we haven't, it's still identical.
Ned Zimmerman: Oh, cool. Interesting.
Okay.
Charles Hall: So.
That's the best definition that we have.
Ned Zimmerman: Okay, that's good to know.
Okay.
Yes, sir.
Mitchell Evan: Continuing on that very good question about, you know, what do we mean by technology?
I think there's at least two layers to that question. One is work with different kinds of assistive technology that are necessary for interest.
requirements. Oh, if a requirement is, you know, programmatic and technical service such that.
Oh.
Mostly screen readers, but then there's other things that are for magnifiers and so forth. There's these types of assistive technology.
That's one layer. Other layer is how many different?
brands and makes and models and versions of those.
type within that type. And that's addressed by the discussion of accessibility supported currently in WCAG 2.0.
where it talks about, you know, that's left to the
That's left in each environment to decide whether.
a wide range public, publicly available or widely available is the term.
technologies, or could it be more narrow, for example, for a company like Trinet?
Everything I just said is just to summarize what WCAG 2.x already says.
So I think we want to address
I think that's,
Those are the things to reference, not to duplicate.
But I do have one question at the end of that, and maybe to Charles or others who might know.
I'm not up to speed on WCAG 3, and whether that extra layer of.
accessibility supported and.
What's the phrase I just used? Commonly available, I think. Like is that also
Currently still maintained until we get through.
Charles Hall: the concept is, of accessibility supported, yes. The working definition and description of it has changed.
Mitchell Evan: So that could be an action as we figure out what to reference. Well, I mean, as a general, that could be actually a really high-level general statement. As we reference things, look at WCAG 2 and 3 as places to reference.
Which I think you made that point already changed.
Charles Hall: Yeah, I think
Our effort might be in identifying any gaps there.
One of the big differences in WCAG 3, just if anyone's not aware, is the concept of an accessibility support set, which allows you, the author, to identify.
what you are evaluating against.
Mitchell Evan: Did you mean author in the sense of authoring tool or something else?
Charles Hall: Author as in the sense of the owner of the content.
Mitchell Evan: Alright, haha.
I just noticed her.
overloading of that in between. But I do — I've never really noticed that before.
Charles Hall: Yeah, that's something that ATAG needs to disambiguate in the opening statement.
Mitchell Evan: Did you catch that?
Ned Zimmerman: Yep.
Mitchell Evan: Thanks.
It's ambiguating. Author.
Yes.
Ned Zimmerman: Yep.
I just wanted to go back. You had said, Charles, earlier on, you were talking about validation, and there was another word that you said you thought might be better suited. Can you remind me what that was?
Charles Hall: Evaluated. Evaluated. Right. Because we're expecting the tool to.
Ned Zimmerman: Evaluation.
Okay.
Charles Hall: Run an automated check against what is applicable to the content at the time of the authoring stage. Not validation means, that has already occurred, a fix has occurred, and we're verifying whether or not the fix matches the expectation. It's a different concept.
Ned Zimmerman: Yep.
Thanks.
Other thoughts?
Charles Hall: I guess to unpack that a little bit more, that the authoring tool validation section 3.3 seems to intend to cover both of those steps.
Ned Zimmerman: Right.
Charles Hall: Because the opening sentence —.
is and provide the means to repair. So once the repair is done, validation would occur, but initially it's evaluation.
Ned Zimmerman: Mmhm.
Right.
Evaluation, repair, and then validation.
Okay.
Mitchell Evan: Would it be fair to say that? Validation.
is basically a subset of evaluation. It's a phase of evaluation.
Ned Zimmerman: I think you could make that case, yeah.
Yeah.
So we've got about 15 minutes left. Are there other sections of this document that people would like to focus on?
A more detailed discussion or other things that this is bringing up.
I'm actually curious, there's a to-do question, comment in here, wondering if CAD, computer-aided design, has accessibility features. I'm wondering if anyone here knows that. I actually don't know that off the top of my head, and I'm
I'm certainly curious about that.
Charles Hall: I don't know, but I do know CAD is essentially based on math.
Ned Zimmerman: Yeah. Okay.
Charles Hall: So there's a, there's a math view of CAD content always.
Ned Zimmerman: Yep.
Right.
I'm muted.
Jutta Treviranus: Yeah, so this gets into the whole vector SVG debate, and this has been a topic within WAVE for a while. I mean, it's CAD and geodata and the many things that are reliant on.
Graphics and.
Potentially, I think Wayne also brought up a few. I mean, it intersects, as was said, with math and math notation, science notation, et cetera. There are a number of older documents that looked at the possibility of SVG being an accessible version of the CAD.
imagery, etc. But, it is a good question to pursue.
So the notion of vector versus — yeah.
Charles Hall: SVG2 is an implementation report away from finally being a final recommendation.
It's a recommendation candidate snapshot.
Ned Zimmerman: Okay.
And thanks for that, Charles. So there's a link to accessibility features of SVG.
in the chat.
Charles Hall: There's a document convention in that candidate snapshot where items in red, if you can differentiate red.
are pre-existing from SVG1.
If it's not red, it's new.
Ned Zimmerman: Okay.
Okay.
So
In short, what that seems to show to me is that the only three ones that existed in SVG1 are the
G tag for defining groupings, the title attribute, and the
A element.
Charles Hall: Yeah, we've always had title. The rest is new.
Ned Zimmerman: That's a lot of new stuff. That's great.
That's all.
Mitchell Evan: Ah, you saw me blank with my mute button. I was trying to decide. Oh, go ahead.
Ned Zimmerman: Okay, all good.
Mitchell Evan: This question about CAD.
I don't know much about CAD specifically, but it's prompting me to think about.
A question that applies to many kinds of offering tools and probably CAD.
And the question is, and maybe it already says this, I haven't looked, but
How do we address
content formats. And by format, I mean something like PDF, or Word, or HTML, or SVG.
Again, I'm more familiar with, I have more current working knowledge of the US and European standards where they say things like support accessibility to the extent.
Available in the
documents like that. So, for example.
If I can't document.
By its formatting, but it just had no capability for text alternatives or titles or anything like that.
Do they get a big fat pass? Or
something else. I'd like the answer to be something else, but it also can't be.
It would need to put responsibility on the right place. Because obviously, you know, if I buy the capital program and it just has no
Like, not just the program, but just even the file format has no capability of storing statistical information. Like, how could I, as an author.
I'll do that, so that's a puzzle which I think is important.
Ned Zimmerman: Yeah, so it's like getting down to the format level support. How do you
How do you,
require authoring tools for formats that aren't.
that don't have a lot of capability for storing accessibility information to create accessible content, and it's yeah, there's a bit of a chicken-egg question there, and, like, how
Yeah.
Mitchell Evan: I think I misspoke, and I think I have a partial solution. I think I misspoke by saying —. Like, we're getting at the off the individual content offer.
Not quite late.
But actually, even the tool developer might be too late. If they are working with a content format that they themselves didn't originate.
So there may be an answer is, there may be a new role here, and it's.
Ned Zimmerman: Right.
Mitchell Evan: Content Format Compiler.
Ned Zimmerman: Oh, that's very interesting.
Yeah, that's a really great point. I don't think that has come up. Charles?
Charles Hall: One of the related topics to that point that we constantly bump up against in the,
in AG is
When the output format is not the web or not consumed on the web.
Because the W3C has zero purview over native applications, for example. But the guidelines that we're writing apply to native applications regardless. so we have to very carefully word.
everything, that is not web.
So if we have a scenario where a CAD author or any other proprietary program author where the output of that tool is never web.
Then it's really not in the purview of this group.
If the CAD output can be web, then it all applies.
Mitchell Evan: What about? I'm gonna, I'm gonna take it back.
What if?
It's a form. I don't know. Oh my god.
native user agents, but could potentially have a
Web-based user rights in the future.
A base is very strong. Microsoft Word documents.
Started out only having desktop. Now they have mobile native software and.
Something on the web. I don't know what it's called.
Ned Zimmerman: Yeah, the web editor, the web-based editor for Office 365. Yeah. Yep.
Mitchell Evan: Like, is that enough to give us blanket permission to talk about everything under the sun?
Charles Hall: Right. In the Word, example, it's not just that Word now has a web-based creation tool. It's the doc format that is the output of the tool can be consumed by a web user agent.
Ned Zimmerman: Yeah.
Yep.
Yeah, there's a web reader for it. Yeah, exactly.
Mitchell Evan: Yeah, that's what I was trying to get at. And I wasn't sure. Sorry. It's a great word.
It's a website user agent.
Is it is that the right word for it?
A website that consumes or presents documents.
I don't know what they call that until the barbecue there, but
Yeah, that's the question.
Charles Hall: Yeah, I think I understood the question to be future-proofing.
Ned Zimmerman: Mm-hmm.
Charles Hall: If if that output
does not
a web consumption method through a web user agent, or a web API, but could, in the near future, how do we capture that?
Ned Zimmerman: And just I want to highlight Charles's comment too in the chat that document formats generally fall under the legal descriptions of ICT, information communication technology.
So, just adding my own, observation to that, that these are probably also things that extend into many standards, European standards, North American standards, and so forth, around ICT more broadly.
Miriam, go ahead.
Miriam Fukushima: Yeah, just in general, the question, like.
Anything that is digital is possibly in the future, consumable for that. So.
Ned Zimmerman: Yep.
Yeah, I mean, I think this question that Mitchell initially raised around.
document formats that don't support accessibility information being several levels removed from an authoring tool that authors those formats and the developers of the authoring tool.
is also similar to a point that I know we discussed a couple months ago, I think, which is around when we're talking about the accessibility of content that's generated by large language models. there's also a similar several degrees of separation where most authoring tools probably aren't also.
developing a large language model that is used as part of that authoring tool. The large language model is probably developed and trained by a third party, and then exposed to the authoring tool's users. So
there's I'm seeing there's a bit of a commonality there, or, like, a recurring theme of
How do we
how does ATAG handle situations where there's several degrees of separation between the thing that is the root of the accessibility or inaccessibility, whether that's a format that doesn't
support accessibility properties or a model that is used within a tool that causes inaccessible content or reinforces inaccessible patterns? Yes, Miriam?
Miriam Fukushima: Yeah, I think we glanced on that discussion when we went through some sections of ATAG and where I said we need to flesh out the section on giving feedback and to.
like feedback options and reporting bugs and accessibility necessities. Because tools will get more and more intertwined, and especially with all the subscriptions and service things.
where you can build tools by combining tools and but for the individual authoring tool, it's really important to separate the single.
authoring workflow. You have the tool, the content, and if it.
includes
authoring tools that could be plugins, that could be services, that could be LLMs, that could be various things, and maybe coded from the same company, maybe integrated from other companies, it doesn't matter.
that,
if you want to evaluate the whole authoring tool to really break it down into the different authoring tools and evaluate each one separately and hold each.
developer accountable separately. Obviously, we don't have the laws for that to really enforce it, but still to write it in a way that every.
feature in itself has to be accessible, and therefore also include the ways to give feedback and to bubble this feedback up to.
the root responsible person or company or.
Whatever. Because if I create a tool and there's, like, I incorporate services, I can't be personally responsible for their things. But if someone reports using my tool, bugs or necessities that concern those things, I then also have to be able to report those things to their services and to further up the chain.
the request or complaint.
Ned Zimmerman: Mmhm.
Yep.
And Charles, comment from Charles in the chat.
which maybe will be the last word for today, which is that ATAG.
ATAG only cares about the human part of these cases, so that if AI consumes content and transfigures it to a new output, then only WCAG applies to the output, but if there is a human user interface to engage with that transfiguration process, then ATAG applies to that.
So that's a good distinction to keep in mind as well.
Unless there's — I'm not sure if there's any last comments or thoughts from anyone.
Oh, and Mitchell, just in the chat as well, Mitchell knows today, as far as I know, even autonomous, quote-unquote, autonomous AI agents have a human user deploying them. I would call that human as filling the applicable role.
That's a good point too. I think we should dig into that maybe in a future conversation 'cause that's gonna be really important as we move towards the developing the new standard.
Making those distinctions really clear.
All right. Well, we're at time. Thank you, everyone. And we'll talk to you — we'll see you all again next week.