Meeting Minutes
Wendy Reid: All right. So right now what we're working on is we're actually going kind of section by section in ATAG 2 to.
Review the current version and see where there's, like, opportunities or gaps.
If we start thinking about.
generative AI and LLMs.
And also just like kind of overall advancements that have happened in authoring tools since the publication of ATAG 2.
So, that's what we're working on right now. we got as far last time as the I think we
We're at the end of B2, so we're now at principle B.3.
which is authors are supported at improving the accessibility of existing content.
so this B.3 is about, improving existing content.
And then author assists.
Does anyone have any thoughts of this section?
Sambhavi Chandrashekar: Is it something like Accessibility Checker included in the authoring tool, like TinyMC editor? Is it something like that?
Wendy Reid: Yeah, so the different, so B.3.1, which is assist authors in checking for accessibility problems.
so, like, 3.1.1 is checking assistance, if the authoring tool provides authors with the ability to add or modify web content.
in such a way that WCAG 2 criterion can be violated, then checking for that criterion is provided.
Tiny MCC is probably a good example.
Sambhavi Chandrashekar: Because they have what is called as the accessibility checker, although it's not a very big rule set.
They do have it.
Charles Hall: It also says in the note that, however, manual checking is the minimum requirement to meet this.
Wendy Reid: Evelyn, the comment that you just made.
shared, I think, is related to this, too.
Do you want to elaborate? You mentioned like they're reluctant to add accessibility checks because they would surface issues the author is unable to resolve. Is this like missing features or broken features?
Evelyn Wightman: the one I'm thinking about in particular is
Authors cannot edit heading levels within certain widgets.
So
The only solution is to rearrange the widgets on the page to get a reasonable heading hierarchy.
But
Yeah, so I think that is a missing feature.
Wendy Reid: Mm-hmm.
I guess it depends, too, on, like, the scope of the check.
Right? Like, if I'm editing a widget, does the checker just check within what I'm editing currently, or within, like, the context of the whole page?
Especially in, like, something where there's multiple widgets on the same page.
Evelyn Wightman: Bahar's report.
What's been discussed here is a whole page.
Sambhavi Chandrashekar: Evelyn, I can also share our experience. we do have many widgets that people can bring and drop into the main page, but.
We really cannot be sure what the hierarchy is on the page. We start all widgets with H4.
And that's always been a problem.
I don't know if there's a solution to that.
To maintain the heading hierarchy.
There's no dynamic detectant set.
sort of heading setting for widgets, I guess.
Evelyn Wightman: Yeah, letting authors adjust those levels would be one solution, possibly the only solution.
Sambhavi Chandrashekar: Mmhm.
Mostly admins do that kind of homepage layouts, and we have that aspect covered in the admin training.
Wendy Reid: So the other requirements, so there's the checking assistance, and then there's help authors decide, which basically, you know.
the the tool, if the checking exists, and the tool relies on authors to decide whether the content accessibility problems are correctly identified. So manual checking or semi-automated checking.
and then it provides instructions.
And then help authors locate, so be able to find the issues.
Status report, so it can receive a status report, and then programmatic association of results. So if the tool provides checks, then the authoring tool can programmatically associate accessibility checking results with the web content that is checked.
Sambhavi Chandrashekar: So, I'm wondering, we're looking at AI-generated.
content, right? Authoring tools that allow AI-generated content.
When AI comes in, could we make better use of that AI? Will it be able to detect.
things like
Things could go wrong, and then
have solutions.
So widget heading, for example, or anything else. I'm just thinking about it in a flipped way, instead of thinking we will have problems and issues when AI generates content, and what are we going to do about it?
Let's make some guidelines.
if AI is involved, is there any positive way in which we can use.
the capability.
to improve the assistance the author gets.
Miriam Fukushima: Well, first of all, to that, I think definitely AI can be used for that, especially because it's more text-based, and but that would also require that everyone has to kind of implement, kind of a dialogue interface for their authoring tools, and implement the, API to.
interact with the tool, and so on. So that's, yeah, where do we draw the line to say, okay, this is required, and where what
of our wishes for those authoring tools just goes into, okay, this is maybe best practices or possible solutions that are not in ATAG, but maybe as additional material around it.
And, that also leans in a bit to the previous, point where.
for example, in our system we do a content management system for websites. And what we have running in the background are cron jobs which are scripts that check the content once a night, and then.
If there are, certain issues, they reported in, configural time interval to the content creators. For example, if there is, problems with the headline hierarchy. So if we, go through the pages, we basically crawl them and just, like, go through the, heading.
hierarchies, and just report to the content creators. This is the articles we found where there is, needs to be checked, and, maybe you can have a look at that.
So, it doesn't always need to be AI, but that also requires that we have full control over our content management system, but not everyone has that. So, where do we draw the line between, okay, this goes into ATAG and we require it, and.
Where do we say, okay, this could be a possible solution and it is surrounding material.
Wendy Reid: Yeah, I'm I'm reluctant to say, because, like the use of AI.
It could be incredibly positive for accessibility checking and content, but it's not guaranteed, and it obviously, like.
like, Miriam, as you said, like, it requires a lot of.
building in of of features that may not exist, or maybe hard to build in, or like just don't aren't feasible. So to require it would put like undue burden on on a lot of products. And I think, like at least, I mean, there might be some like a small adjustments. But I think the way B.3.1 is worded, at least, like
We don't actually have to make all that many changes because it
kind of already captures all the features that we probably would want in terms of like informing the author, detecting the content, identifying the content that needs to be changed.
So we may not have to make very many adjustments at all, at least in this section.
Sambhavi Chandrashekar: so this cron tool that you are mentioning, is it a part of your system?
A content management system, because is it?
Miriam Fukushima: Yeah. Well, it's basically a script that you write. You can write it. However, you want like you. You just write scripts and they run on a certain schedule. And, depends on our customer what he booked, but obviously, the customers that want to be accessible and are not required by law can obviously choose.
but, yeah, you can
do certain things once you know how the page is gonna look. That's why we put it after, and then report, and leave it up to the customer to fix it. but, yeah.
Sambhavi Chandrashekar: Right.
Alright.
Yeah, so that kind of nightly checks are really good for even checking regression, especially in a programming environment, but in for an LMS, like, we have to actually purchase.
an automated checking tool separately. So
Anyway, we will go back to what Wendy said and leave this section as such, probably, without too much of changes.
The B one.
Miriam Fukushima: Yeah, in general, I'm okay with this action. I just was wondering if we could.
Maybe formulated a bit clearer that what exactly is required.
Because, actually, it's all in the okay,
if authoring tools provide authors with ability to add or modify web content in such a way that WCAG whatever we are referencing then can be violated then. But.
I don't know. I feel like that's one of the points that quickly overwhelms the
developers, and how much they actually need to provide.
Sambhavi Chandrashekar: One, I mean, this is not relevant at this point, probably, but.
referencing 2.0, even if we reference 2.X or something, when 3 comes in and they both coexist.
Would we want to support best practices or regulatory compliance? That question will also be there.
Wendy Reid: Yeah, we'll have to figure out how to balance,
that, but I wouldn't I'm not too worried about it, because I think the underlying principle still applies, where if you're an authoring tool, I guess, like, it's an interesting, like, wording to say, like, if
your tool can allow the development of content in a way that violates WCAG, when realistically, like, unless you have very, very, very few features in your authoring tool.
That is always a possibility because you can mess with heading structure. You could make a bunch of text bold or italic without it being properly marked up that way. You could change all the colors on your website to make them, you know, really hard to see.
You know, there's, like, you can put a bunch of images in without alt text. there's a lot of ways, without your tool being incredibly strict.
which I suppose is possible, but I imagine probably wouldn't fly in most contexts. There's also, like, I guess the tension, too, especially with, like, something maybe
I mean, with a lot of authoring tools, is that, like, there might be a completely valid reason for why you're making the content the way you are.
that could even be an accessibility reason. But, it violates some rule while following another.
Sambhavi Chandrashekar: Yeah, we have.
We have to provide an escape route.
Otherwise, we'll be stifling creativity. Like, even when we say, unless you add an alt text, the image will not be saved, the escape route is you can mark it decorative.
And then go take care of it later.
So to what extent the authoring tool is responsible and.
which are the areas that the authoring tool is not responsible. Maybe that kind of a declaration would make it easier.
Sambhavi Chandrashekar: For users of that tool.
To say we have to be careful to manually check this and this and this, and the tool is taking care of this and this and this.
Wendy Reid: I think it's already kind of balanced in the way it's phrased now because it's really just saying if the opportunity is there, like if it's possible to create inaccessible content.
The tool should provide.
a means to let the author know. But it doesn't say that the author must.
you know, fix all the bugs, that the author must or, like, that the tool cannot allow the author to proceed without fixing the bugs. We can't
force that, nor should we.
Charles Hall: I comment on a few things that I'm very unhappy with. You pointed out one of them, which is the word if.
There's no such thing as if.
Any content that's edited presents an opportunity for risk.
But then it goes on to say.
an individual success criterion.
and that the tool either checks for that individual success criterion or manually provides the author with instruction for detecting that individual success criterion. So what that also fails is the fact that.
In almost all cases, there will be an array. There will be multiple success criterion to check for any individual content change.
And that's not indicated here. It doesn't say you have to loop through this for every single criterion.
But then the wording is also super confusing between the normative and informative parts and then the supplementary parts.
The criterion basically says.
that
The
the the
Change should be
identified in a way that it's checked either automatically or manually.
If it's manual, then instructions for how to detect it manually are provided.
So in the note, in the informative part, it then says, manual checking is a minimum requirement to meet the success criterion.
Which isn't
clear in the normative part. It's a note.
And then there's a supplementary implementing ATAG 2.
Levels of checking automation. And in the supplementary part, it says manual is not recommended.
for the possibility of user error.
So none of this is clear whether manual is normatively required.
Because it doesn't state it, and then it does, and then it says, don't do it.
So I'm not happy with the if. I'm not happy with the fact that it centers on a single criterion, and it doesn't clarify manual evaluation.
Wendy Reid: I mean, that's probably an area that part about it, the kind of like waffling between manual, semi-automated and automated.
Like thinking about when ATAG 2 became official 2015, like we had automated tooling back then, but it wasn't nearly as advanced as it was today. And I wonder if like this is like an opportunity, like technology landscape has evolved. We can actually.
I think be a little bit more confident in saying the kinds of tooling and checks that can be run.
especially now with, like, generative generative AI and LLMs and all that all of that, where we can say, like like, before, we were like, well, like, you can do some automated chat, like like, ACT, even, as an example, wasn't
I'm trying to remember dates. ACT may not even have been published in 2015.
And so, like, automated checks were not nearly as advanced in 2015 as they are today, and so we can be a little bit more confident about that point than maybe we.
Might have been in 2015 or 2013 because.
Charles Hall: Yeah. Okay.
I absolutely agree that the how.
that this gets implemented and supported and the outcome of it has dramatically improved. My challenge is with the what is the actual requirement. It is not clear at all.
Wendy Reid: It struck me, too, that it
I mean, this is just us being spec authors, but it feels to me like
3.1.3 and 3.1.5 and 3.1.5 are very similar in that locating and then programmatic association.
I mean
in my head, I'm like, if you're locating them, then you're probably also programmatically associating them so that they are locatable, but
There's probably a lot of revision, just to clean up a section, and also modernize.
But the principles still hold.
I think this, like, it probably actually, speaking of automation and all of that, three, two, which is assist authors in repairing accessibility problems.
It's almost like
Now, with a good example with AI, generative AI is like assisting authors with repairing the issues.
Automation has gotten so much better, so has automatic repair.
Is there anything more we need to say in repairing now that we have these kind of new tools?
Charles Hall: Yeah, I think the first thing that I noticed is the gap between.
3.1 and 3.2, which is, in 3.1, if
something is is detected.
There is the ability to help the author decide the detection.
Not the solution. So, in repair, it should have the same
Help.
There's never one way to fix a problem. So if the tool provides the author a recommended solution, that's a recommended solution.
So.
How do we help the author decide between available solutions and not just have the tool?
issue a command.
Wendy Reid: Yeah, the way it's worded, it does say then repair suggestions, you know, brackets around the S, are provided.
Which, I think, leaves room for the fact that, like, there could be 3 solutions to a to a bug.
I think the the further point, though, is you can give them 3. You can give someone 3 solutions to a bug. But are you explaining why there's 3 solutions? And are you explaining the pros and cons of the various solutions? I think this is like a challenge I run into even.
Maybe less so in, like, content production, but definitely in code development, where the fix for an issue.
Um for like a component or something.
isn't necessarily sometimes it's easy sometimes. Oh, you forgot to put the right aria attribute on that on that button, or you know, whatever. But other times it's like, well, you could fix it this way. You could fix it that way, or there's a you know, there's a 3rd fix, and there's pros and cons to each of those.
And you have to decide.
I think we have that's open, but I'm curious if we
We want to say something about, like
It says, like, there is a note about automated and semi-automated repairs possible.
and encouraged for many types of web web content authoring, WCAG problems. however, manual repair is a minimum requirement to meet the success criterion.
So we don't really say anything about like, well, what happens if there's multiple solutions?
And maybe this is where, like, generative AI helps, because
Now we can even, we can give you solutions and we can possibly gather data for you on why the solution, the differences between the solutions.
Charles Hall: It also suggests that
automated and semi automated repair
is assistance.
And doesn't mention if that repair
It there's no.
confirmation process that a repair was fixed automatically.
Wendy Reid: Okay.
Well, I guess you'd see that, like, the error disappear, or
But yeah, that could be clearer.
Wayne D: Yeah, sure.
I really think that issue of ongoing.
Notification of repairs.
Very important, especially with,
AI, because it so happily makes repairs without telling you.
And can change a whole algorithm.
It's done it for me many times.
I think that one thing is that,
the capability of the level of assistance that a person can get from a program today compared to what was.
Possible at the time that this was written.
is really vast. And I'm wondering whether we just simply look at the issue of manual and automated as what is physically impossible to automate and what's not.
And if it can be automated, I mean, it
You know, a generative AI can read a document like WCAG 2 and really know what it means because so much work went into making it precise.
It's like they really avoided ambiguities. Humans can't read it, but AI can.
And I think that's a
something to consider in this section. And you know, maybe we need to look at cases, you know, are we
continuing authoring of something that we know has real flaws in it? Are we continuing? Are we authoring something that we know has been developed correctly, and we're extending it?
And of course.
Whenever we add something that it knows absolutely it can't check, we have to do it like, you know.
alt text. There's no way that a program can give intelligent alt text. It can just
Distort a few bits and it doesn't know what it's doing.
You know, it can see an elephant as a bus. I mean, it can do that.
Wendy Reid: Yeah, we might have to, like
for the next version of ATAG, like, really rethink.
This this section in terms of like.
You know, what does all this automated checking thing, what are the limits of automated checking?
And then, like, what does it look like? Because now it can be whereas before, you might have gotten, like.
a pain of, like, notifications. Now, it might just make those changes for you, and not
Not necessarily tell you, or, you know, tell you in kind of a tangential way.
Just to keep the ball rolling because I want to get.
Hopefully we can get through a lot of this section today.
I want to move to three.
B4, I don't know why I wasn't saying 3, 4. B4, authoring tools promote and integrate their accessibility features.
B41 is ensure the availability of features that support the production of accessible content.
this one, I think, in the in the new context, is kind of interesting in the sense of like.
What does this look like?
in more generative tooling, because I don't think I've ever seen I definitely haven't seen, like, oh
Like, you don't have as
It's not that you don't have as much control, but, like, the tools kind of decide how the content gets structured, and you don't have, like.
you know, the rich text editor bar or anything like that, and in some of these tools, it just kind of does it.
What is what is exposing accessibility features look like in that context?
Sambhavi Chandrashekar: Hearing that makes me feel like
At that point, they were looking at accessibility features should not take up space and attention.
But some people will be interested, and they will turn them on.
Vis-a-vis, like, putting them out.
Right and center and saying these are important main features.
In the tool.
Which will make that redundant or unnecessary.
Miriam Fukushima: Yeah, well, I think this could also be a huge debate because I think what I often see is that accessibility features are just hidden away under settings in accessibility, which is fine that there's an extra.
spot to look for. And it's kind of also learned behavior that we know it's there now. But.
In the actual primary user interface, it's not there oftentimes. And even though some of the features are just as equally important as any other editing features. But then again, you could argue, okay, if they are all in one spot, then they are easier to find.
So what belongs into among other tools, and what doesn't could be up for debate. But I think that they should be easy to find, at least with one or 2 clicks and.
I feel like there's also the like report missing features.
point missing, that if an author actually knows, okay, I should.
be able to do this, or edit this, or make this conformative, then but I don't have the tools to do it. For example, I can't edit my captions, or extend the time, or restructure the timing on the
on the captions, but I should be able to do it, then I can report this to the developers of the authoring tool and don't have to look up on their website how to report bugs and go through a whole ordeal of how to actually reach the developers, but there should be an easy way to give the feature a.
This is missing.
Evelyn Wightman: I really like what Miriam just said.
I am thinking about
using LLMs as an editing tool.
Is if you can prompt.
the LLM to fix an issue and it can do that.
Is that sufficient to say, yes, we've exposed a way to fix this? Or does it actually need to be discoverable?
Because you can only prompt the LLM if you know that needs to be done.
Miriam Fukushima: Yeah, I think that goes a bit into before, too, the documentation of it.
Of course, you can't take
demand how documentation is to be done, but, like, just little question marks on or tooltips that explain why something is important, even if you do it precise and then have a.
base where you have more detailed documentation. I find this very helpful and important.
And,
documentation is not only how to use something, but also why to use something. And maybe if we could put that in the documentation.
part that the how and why need to be answered, then maybe that's a good way.
Charles Hall: Yeah, I think
And I know, overall, ATAG has a way to conform to it, similar to WCAG, where it's, like, all or nothing and binary, so it's kind of a given that.
If you have features activated by default, you also provide feature instructions.
But I think
This is something that needs
wording that describes how critical the pairing of those two things are, and it applies to almost anything I can think of, as simple as, like, the feature is that I have the ability to add an ARIA label to a button.
So that feature is on by default. As an author, I can use it.
if I don't know exactly what that means and when to use it and why to use it and when not to use it, I'm creating risk versus solving it.
So it feels like the feature instruction needs to be part of having the feature.
Sambhavi Chandrashekar: I'm going back to
accessibility tools and hiding them or exposing them. I mean, it's not a part of the tool. Say, HTML editor, when you go to add a table.
there's a feature that allows you to add a summary, there's a feature that allows you to add a row header or a column header. Those aren't things that we need to actually explicitly.
Turn on, or turn off, or
get the author's attention to.
But if there is a call out that while you're doing this.
This is an accessibility enhancer or something.
And that might be useful.
Miriam Fukushima: Maybe we should divide into features for, well, accessibility features for a certain widget and general accessibility features that everything.
that is general to the authoring tool or to personal settings of the user of the authoring tool can be hidden under Accessibility Settings, but everything that is essential to a feature or a widget needs to be,
equally present as any other editing element.
Sambhavi Chandrashekar: So I'm clarifying my thinking. There are two types, right? One is for the author.
If the author needs assistance.
In using the tool, probably we were referring to that, to hide it or to reveal it.
But even that should be built in.
I mean
I don't know if I'm
Making it too simple.
But it should be built in. Could we name one?
thing that an author will have to explicitly start.
To be to make that tool
able to
Provide accessible authoring.
Wendy Reid: I mean, one part of 4.1 is
feature prominence.
Wendy Reid: So, all accessible content support features are at least as prominent as features related to either invalid markups, syntax errors, spelling errors, or grammar errors.
I can see a lot of tools fail this one. But.
It is one of those things where, as long as the notifications
or the, I guess the discoverability is.
the same. However, like, I do think.
the example Charles gave, and you gave somebody is like.
if I don't know, like, when I if I generate a table in my tool, and I see row headers, and column headers, and summary, and I don't know.
what that means. Like, why would I have a summary on my table? Or why would I have a row header or column header when I have, like, the row?
I might delete those, and not know
Oh, it's just extra code. I don't need.
So I think there is something about there, like about providing instructions or clarification about why something is present. I mean, like tools do this all the time. You have, like, the first time use kind of tool tips and things like that. But that might be, especially for accessible features, it might be.
helpful to have those explained why they're being suggested, especially if they're new to a tool or even new to an author.
Sambhavi Chandrashekar: Wendy, I was also thinking of
Suggesting that we could have a community document.
Where right now, we're just capturing everything in minutes.
A true minutes.
We don't have a document where we name the
item, like D31
and then assign some thinking or some insights that came out of our meeting against that.
We haven't, like, filtered and
represented our chats discussions all these days in terms of what part applies to which explicitly in a document.
Does it make sense?
We just have minutes right now, right?
Wendy Reid: we have a document. I've been I have to update it. I have to go through again and do, like, a big update.
Wendy Reid: Everyone is allowed to I'm pretty sure the permissions are set that anyone can edit it, so
Sambhavi Chandrashekar: Okay.
Sorry, you must have mentioned it at the beginning and then it must have gotten lost. Yeah.
Okay.
I'm glad at least I refreshed my memory.
Got this link.
Wendy Reid: All right. Anything else with —.
for the B.4.1.
So I guess actually related to what we were just talking about is, and oh, this is the very last one. B.4.2, ensure that documentation promotes the production of accessible content.
And I guess, like, relate to what we were just talking about, like
We say doc like, in this case, we're saying documentation, but documentation may be too far.
Or, like, too detached from the interface.
like, it's helpful. I look at docs all the time for all sorts of projects, but if you're working.
I guess, like, kind of to go into, like, Charles's point from earlier, like, if you don't know
what an ARIA label is, and you don't know its purpose, you're not going to look it up in documentation to find out.
Or you may or may not look it up in documentation to find out what you're doing with it or that it's there.
So
You almost have to, like, documentation is helpful and should be present, but may be too far detached from the interface itself to be helpful.
Miriam?
Miriam Fukushima: Maybe we can. So, first of all, the point from earlier to that the documentation needs to provide a how and why.
And, then maybe we can also add a point, that in short instructions on the.
features or buttons or whatever are also required. I don't know how far we can go there, but that at least,
That it's not only that it can't be ignored without
at least seeing a short sentence or whatever.
MJ - Mary Ann Jawili: Yeah, I totally support the idea of, like, some bringing the information or the why closer to the feature. One thing that Abhinav and I worked on was, like, maybe adding some really short fact.
hey, your alt text will and something to compel them to,
add to make their, to add this accessibility information. So like, you could say like.
If you add alt text to this image, it'll
it'll make your information available to, I don't know, some percentage more users or something.
Just adding something like that might be really helpful to encourage people to.
create accessible content.
and it would be, like, right there on the
right there in the, same place where you're actually adding an image. there would be a field to add alt text, and just, like, a little line, like, descriptive text.
Or help text right next to the, alt text box that describes, like, why you might want to do that.
Instead of just putting it out there.
Miriam Fukushima: Yeah, and maybe we could also just get rid of the sum in rational.
At the very beginning, just authors need support.
Period.
Sambhavi Chandrashekar: Yeah, to
add to what was being said, like a one-line inline help and a link to that relevant section in the documentation, online documentation.
Miriam Fukushima: Yeah. Maybe I would formulate it as, reference the relevant section in the, broader documentation because depending on what authoring to it is, it's not by via link or anything.
But other technologies?
Wendy Reid: Sinking, too, actually, in the context of, like, generative tooling, where, again, like, you may not have
A toolbar. Or,
or at least not initially. I wonder if, like, having something around, like, promotion of accessible features, or accessibility features.
Where, you know
go into Gemini or something and say, make me a.
You know, I want a picture of a of, you know, a cat.
And it generates that, but it also at the same time is like, oh, and I've also generated alternative text for this image. Here's how to use it.
Instead of, like, still putting the author in the position of having to remember, or,
request explicitly.
Miriam Fukushima: Yeah, maybe. Well, the problem is like, with AI, it would need to be trained.
To do that.
But maybe that AI agents or other AI authoring tools need to have a shorthand for an accessibility prompt. So if you.
have some your AI build something that your prompt.
that you get, like, an automated button or something to do the same prompt accessible, or to have a prompt, now make it accessible or something.
or what do I need to, uh
to watch out for to make it accessible.
and just have it as an automated system that comes right after to promote it. Like, if I put, okay, it would generate me an image, and then I get a button with, how to make this image accessible.
And that generates a prompt for the AI to make it accessible, or to tell you what.
an accessible image is.
as a promotion method and have that as a requirement, at least for AI.
Because, training the AI to do it automatically might be really difficult, and it's no guarantee that even with an automated prompt, it would
Tell the truth.
But at least would fulfill the promotion.
part, and would help
sensibilizing people for that.
and also give a shortcut to do it, so they don't have to rewrite their prompt or know how to phrase it. But just as a second question for AI that you can do on a click. It's much easier than.
having to think about it, or if it's just text next to it, I can read it, I say, okay, yeah, but if there's a button, I can click.
just to show me the answer, because I'm curious, it's much easier, and I think that would be easier to get into requirements.
or best practices or whatever, but like that we then formulate the requirements general enough to include that.
And then in best practices.
suggested.
Wendy Reid: Yeah.
Alright.
I think we've done our review.
Which is amazing. I didn't really, I snuck up the end of the doc, the requirement snuck up on me.
So the
And next.
thing that we have to do as a group, which will start, I guess, next week, is we want to start looking at use cases and requirements.
And so like putting out of our minds the constraints of ATAG 2 and just thinking about like, what are the current use cases and requirements for authoring tools, or even future use cases and requirements for authoring tools. So.
For next week, when we meet, come think having big thoughts about all of the use cases for, different authoring tools, other ones you've used, or ones that you've had experience with.
And we will start putting those together and discussing them.
But thanks, everyone. It's been really helpful. We have a lot of good material. And we will talk next week.
Again, very soon.