Meeting Minutes
Wendy Reid: First thing I had on the agenda that I wanted to talk about was, from last week, was the breakout session.
Wendy Reid: Proposals? So I came up with two.
these are the breakouts for TPAC, so, usually I think they're doing it over multiple days, but typically the Wednesday of TPAC is breakout day, so it's, shorter sessions, different topics. I can submit a proposal. They're both quite similar. So part of me was oh, I could submit two proposals and see if one gets accepted.
But the worst nightmare would be they both can't accept it.
And they're both kind of similar. So I'm more curious what people think of these two.
which theybetter changes we can make to either.
Ned Zimmerman: I think my instinct is towards option one, just because it does sort of —.
place the emphasis on the tools and sort of imagining, imagining.
authoring, I mean, as you say, content authoring in the age of generative AI, but with a focus on the authoring tool.
And it it just seems to me that that.
While they both address a similar concern, that does place the focus on.
the work of our group and what we're working towards.
Miriam Fukushima: I agree.
Evelyn Wightman: I haven't read these both thoroughly, but I'm compelled by the argument which has been brought forward.
Jutta Treviranus: Yeah, it's too bad that I wonder, is there and of course, there's no way to sort of try to cover both within
merging them somehow.
Wendy Reid: I could try. I mean, I think there's a lot of overlap between them, and so, the first
Or this option 2, we could, include it as part of our
Jutta Treviranus: Reimagining. Yeah. Yeah.
Wendy Reid: Presentation,
start off with, hey, what's the current state of things?
And what are some of the challenges we're already seeing? So I think a big thing is emphasizing to people there are challenges right now and there are opportunities. We're already seeing both. How do we leverage what's going right and be conscious of what's going wrong.
Jutta Treviranus: Yeah, but I don't think it would be that hard to make it turn it into one.
Wendy Reid:
Okay, I'll make some adjustments to kind of merge them, and then I will submit that, hopefully.
It'll get accepted, and then we'll have a session on the Wednesday as well.
That was easy. All right.
So
Wendy Reid: Put the link for people.
The main topic, of course, is use cases.
I did a little bit of
reformatting the other day.
Basically, just to get it into this,
as a structure. What I thought was a bit interesting as I was
Doing this is that I realized
The as the as a part is important.
But
Maybe not essential when we're trying to think of, what are the core use cases or requirements for either.
because it's really, what are the actions that need to be done, and then what's the similarities between,
A designer and a teacher or.
a developer and an influencer, and
How do we narrow down.
I think we started with these kind of top level ones.
This one's kind of the, the users must be able to author accessible content, I think has proven the easiest so far.
I also realized as I was going through this that some of these sections don't actually have content within them.
Evelyn Wightman: Comment on Option 2 goals: They seem rather wooly. Broad and ambitious. I don’t know if I’d find them compelling as an attendee.
Wendy Reid, Ned Zimmerman:👍🏻
Wendy Reid: And it might just be that the core
The core high-level use case is the use case.
Jutta Treviranus: Yeah, I mean, I think things have changed significantly because when we ATAG 2, there were stillmany authoring tools made it impossible to author accessible content.
but the the core functions I I think it's really useful to have these different perspectives, so we don't miss specific needs and constraints. but we could
List not as a group, but somebody individually, or one of us individually, could list, sort of, some of the functions that are required by each of them, and then see what the commonality is and pull out the essential functions.
Wendy Reid: I mean, we started doing that, I think, over over here, where we had the authoring tool types and functions, and I wonder
If I guess to that point, so we have tool functions and then I guess the flip side of that is
User functions?
Jutta Treviranus: Yeah, or user requirements or, yeah, something of that nature.
Wendy Reid: I'll call it —
Function is maybe a bad word for this, but
you know, because we, talked about this, I think, in the role I think we have,
application not application rules, we have human roles. The human roles and actions, actually. And that is that we have authors who do authoring. We have developers
Editors
Consumers
Auditors
And maintainers.
And even some of these possibly overlap with each other.
because arguably, an author and a developer are doing the same thing, just with different content types, possibly.
Evelyn Wightman: I thought the author was creating stuff using the tool and the developer was creating the tool.
Wendy Reid: This is the interesting, I guess, challenge with authoring tool definition because an authoring tool developer can create an authoring tool using an authoring tool.
Because a developer environment is also an authoring tool.
Evelyn Wightman: Yes.
So in that case, they're both developer and author.
Jutta Treviranus: Or they could be creating something that isn't an authoring tool, but developing some software or code, right?
Wendy Reid: .
That's why it's, they're, Venn diagrams with massive overlap, because essentially,
Jutta Treviranus: Oh, but we do have
Yeah.
Wendy Reid: The author, I mean, we could also even say creator, right?
Miriam?
Miriam Fukushima: Yeah. I see it morea, workflow that can loop in its on in on itself. Kind ofyou have the developer, that, creates an authoring tool, but it can also use an authoring tool to develop it.
Then you can go back on that loop, and on the,
Basically, perpendicular to that, you have the authors, the authors using the authoring tool.
And to have it maybe more visually than describing it as text would be maybe a good.
Addition to materials.
But I think it's important to that we don't have to that there are two roles, basically, the developer and the author, but, if we have a developer developing an authoring tool.
that we evaluate, then we don't have to, at the same time, think about the authoring tool he uses to develop the
authoring tool.
a person using ATAG has only toneeds to take one role at a time and look at it separately.
Wendy Reid:
It makes me think that there's
It's essentiallya creator role.
And the creator role is, it can be
creator of the authoring tool. It can be an author using an authoring tool. It is the originator of
of
Tools or content.
Then there's a maintainer role, and that can be people who serve as,
Editors
Developers who are maintaining tools, using authoring tools to maintain.
to maintain product.
And then you have
consumer roles.
And consumer roles can be peopleauditors, end users.
Evelyn, go ahead.
Evelyn Wightman: Yeah, I think it gets simpler if we're describing roles in relation to one tool.
So, the developer of this tool, that's Klingon. It doesn't matter what they developed this tool in. Someone using this tool to create something else.
They're an author, it doesn't matter what they're creating.
At least in France.
Wendy Reid: And I think for us, it doesn't.
We're setting up the requirements that the tools need to be accessible and create accessible content, but it doesn't actually
matter what the tool is, if that makes sense.
Because we're not telling you what tools to use or we're just telling you what the tools have to be able to do.
Developer.
Does this feel because I think then, the use cases become
Is this a creator use case? Is this a maintainer use case or is this a consumer use case?
If that makes sense.
And I think there's gonna be a lot of overlap, particularly in the creator and maintainer use cases, because, for instance,
The
Sorry for scrolling. Users must be able to author accessible content, and users must be able to maintain accessible content.
Are, very similar use cases, but with,
Excellent.
Evelyn Wightman: I think it makes sense because.
We're not, in the standard, we're not addressing the creator of the tool.
We're saying the tool must do this.
And then
the only
humans we talk about are the people who use the tool to create, maintain, and consume content.
So we don't actually need to worry about how to talk about that tool developer in the standard.
Wendy Reid: Yeah.
Because in our
Let's do this. Our authoring tool requirements.
we're not saying, as the creator of an authoring tool.
the creator of the authoring the wording for the requirement is not the creator of the authoring tool must be able to support the addition of accessibility features. It's the tool itself must be able to do this. And if you're the developer of a toolthat.
You're going to look at this as a
You know, as a ticket in the.
in the sprint of development.
Evelyn Wightman: I see developer as in creator and maintainer.
Wendy Reid: Because there's the developer that I mean, there's a development role in creation of the tool, but then, obviously, once the tool is created, the longer term
Maintenance of that tool.
It's still a developer.
Evelyn Wightman: Okay.
Wendy Reid: I mean, I think the big difference between, creator and maintainer, I think there's a lot of overlap, but it really is, either the originator.
of
The originator of a thing, or the
entity that takes an existing thing and modifies it.
you bet.
Jutta Treviranus: Yeah, I think what the essence of what we want tothe the actual name of the role is not necessarily so critical as the actions and responsibilities of these individuals. Right? The what actions do they need to take? And What are they accountable for, or what control do they have over.
either the authoring act or the developing act or whatever.
So whether the monitoring and evaluation and adjustment or whatever is done by the original creator or the developer or whatever, yeah, it's more important to capture.
What are the types of actions that?
are involved in the the this.
overall ecosystem and who's responsible.
But I could — I can be persuaded otherwise.
Miriam Fukushima: Yeah, I also think, I think that's why we originally wrote actions in the top because the.
actions are clearer,whether I'm athe developer that created the tool and later maintains it or sells it, andsome company maintains the tool.
The important thing is
everything that is accessing the code and the functions of the tool in the way that it can be changed and has influence on the content that it creates.
And then there is the ones using the tools, whether, it's,
whatever authors in context of schools, ordevelopers testing, or that doesn't matter. It's the.
the action of using the tool. So.
Miriam Fukushima: Yeah, but I would think, evaluation is a separate.
third responsibility to basically
apply ATAG
In a validation sense and not as implementing
View
Because you have three actions towards the tool and two ways in which you can use ATAG.
Dallon. Au: Yeah.
Yeah, thank you.
I'll probably take some time to look through the document, because I think it looks quite a bit, and I'm a screen reader user, so I'll just take a bit of time to look through that.
I'll see what I can also contribute in this area as well.
Wendy Reid: Yeah, of course. And if you ever have questions, you can ask here or send me an email or anything.
Wendy Reid: so
Miriam, to get to your point.
I think that's why I have auditor as, a consumer role, because when you're an auditor or an evaluator, you're not editing the content, but you're
You're looking at it and it's kind offinal state and not making changes to it.
Just auditing it as is. But Evelyn, go ahead.
Evelyn Wightman: I'm going to pretend that this is a
A courtesy question for Dallon. What's the goal here?
What is the output we're trying to get to from all of this? We keep adding things.
Wendy Reid:
So one of the things that makes
future development of a spec very or a lot easier is having a foundational set of use cases and requirements. So that's what I'm hoping we can get to get to, is,
A document that we can use as our
foundational set of use cases and requirements that we want to make sure are captured in the resulting.
Standard.
And specification. So
As a community group, we're allowed to publish reports, and so I actually think we should publish whatever our final product ends up being.
Evelyn Wightman: Do you have an example of a document like this.
That is finished.
Wendy Reid: https://www.w3.org/TR/epub-anno-ucr/
Wendy Reid: This is, the most recent one that I
I've been using
This one is for an annotation spec that my other working group is working on
and it basically just covers, core annotation-related use cases, so,
Annotating a textual section. A user decides to annotate a textual section of an EPUB publication.
And these are the things that then, as we're working on the actual specification, this is kind of what we come back to. And we've even had discussions where we've realized we're missing a use case.
and use cases may be incomplete.
But I wasn't part of the development of the use case document.
I'm hoping we can be a little bit more
I mean, stuff always comes up, but
There's a
That's the point of this exercise, is to get to something that we can refer back to constantly as a guiding document.
Miriam.
Miriam Fukushima: Yeah, what I think is important that we,
kind of find precise terms for.
The roles, so that,
It's not so much a topic of discussion, Nita, when someone.
has an authoring tool before them to, and needs to. For example.
Start it or develop it or change it.
Or actually validated for whether it's worth using.
that they can
find the right perspectives, from which to look at ATEC.
And
In that sense, I don't know if it's
necessary to.
Distinguish between creator and maintainer.
Or if that's not, in the end, the same thing, if I start a new, programming a new authoring tool, or if I modify.
An existing one.
the same things apply. It's a technical approach.
Whether but then, if I
use it, either because I really need to use it, because I need to create the content, or because I use it to evaluate it.
that's
The other side.
Maybe.
Dallon. Au: so sorry, this is Dallon here. I'm just curious, in terms of
use case wise,
Are we supposed to add in more?
Specific use case, you know, or what what would be
The main objective, because when we talk about authoring tools.
in my head, I would probably think of things
markdown editors, code editors,
I think for me, or things. Notion, for example, a lot of these tools become quite inaccessible at some point, right? Especially when more functionalities get placed into it.
Wendy Reid: It is.
Dallon. Au: I personally, as a user, I don't really have very good experience with, things like Notion,
what would you call this? Obsidian, those mainstream tools that people would
users would generally use, just for adding in of content.
So, I just want to clarify a few things. So, one thing that I'm trying to understand is, when we talk about altering tools, one is the point where we talk about how accessible we can make it for editing-wise, and then the other aspect of things is.
when the
content comes out, how accessible is it for everyone? Is that the goal?
Wendy Reid: That's exactly the goal. So,
we're putting together so our very first step was to put together just, the broadest set of use cases, and as specific as people wanted to get. So you might see in the document,
and right now we're in the fourth tab. It's,
preface with for editing, because we're I'm actively editing it, but you can look at the other tabs just to see kind of where we
Where we started from.
So there'll be things as an authoring tool developer, I want my tool to use AI to generate Markdown.
As a user, when I create content, I want to be able to export that content into other accessible formats.
So, what we're doing now is, now that we have, a lot of these, and we can continue adding, the hyper-specific ones, because those are really helpful.
but now that we have quite a few very specific use cases, it's looking at what are the commonalities between those so that we can create a set of, kind of,
Foundational.
use cases that represent.
As much as possible,the full range of what we want to cover with a standard.
because the stand I mean, we have so we're working from ATAG 2, but we know with the with generative AI, and then just other advances in the last 11 years.
That, we need new new
requirements that actually reflect, how content is authored today, and not just content, but, content is in,
text or video or audio, but also thingscode environments.
toolsNotion, kind of very fully featured toolsNotion or Obsidian.
I think we have we have in thisthings to research slash define tab.
We have an incredibly long list of tool types that we've been trying to also
distill into, kind of, essential functions. So we have thingsweb content creation tools, educational content creation tools.
Code creation, marketing.
generative AI, design creation.
and obviously there's lots and lots and lots of tools out there, but how can we
How can we distill them down into their most essential functions?
and create standards for them.
Dallon. Au: Right.
.
Okay.
Wendy Reid: Yeah, and our standard will cover, so it's covering, it's focused on authoring tools. So we're covering the requirements to create accessible authoring tools.
And the requirements for accessible authored content. So the content that comes out of these tools.
That's our a really simplified way to describe what our scope is. Because for us, we don't get into the
the content definition because that is owned by WCAG, the Web Content Accessibility Guidelines.
So what determines what makes a piece of content accessible is WCAG.
But our ATAG covers
how the tool should be to make that content accessible.
And how accessible the tool should be to people with disabilities in the creation of accessible content.
Dallon. Au: So, so, would something be,
An accessible, content
accessible content, a creator would have to
For example, okay, I'm just thinking out of the box. For example, it has to have a valid accessibility checker.
that follows, say
WCAG, for example s that, is that, overstepping, or is that, okay, that's what is meant to be?
Wendy Reid: No.
That we have ATAG 2 even has a requirementthat already.
So that's the kind of thing that we can specify is to say, you know, authoring tools must have an accessibility checker that checks against WCAG.
Version, whatever,2.2 or 3. We're looking at 3 as well.
That's something that's in our realm.
Dallon. Au: Okay.
Jutta Treviranus: Which brings up the thorny question of, I mean, ATAG 2 was very much all references to WCAG, right? I mean, the determination of what is accessible was WCAG.
Do we go beyond the current state of WCAG? And can we depend upon WCAG?
all of the requirements, especially as we get into these very, very fuzzy areas, where there is no longer a user agent requirement, etc.
But that's not what we're talking about now. We're talking about the use cases. But I think, I mean, basically what it's used for is to determine compliance, right? It's to see whether we have all of the.
Wendy Reid: Yeah, we're gonna have to
Yeah.
Jutta Treviranus: the information we need to determine whether we're actually meeting the goals of of compliance to it.
Wendy Reid:
Yeah, and I think, so use cases, we've been focusing a lot on the use cases side, but the other half of this is the R and UCR, which is the authoring tool requirements.
And those are right now we kind of have them structureduse cases, but they are very much more, it's less a use case and more what do we demand of the authoring tool to achieve those use cases? So it'sa slightly different framing.
But it
I mean, it's basically just a direct reflection of what the use
The user needs from the use cases, how the tool has to,
accommodate those needs.
and then, right now, because we have we don't
just to look at, as an example of.
the EPUB annotations, UCR document that is
Just a helpful example.
All of the use cases are very much a user, because this is very much a
specification targeted at end users, so I am the reader of a book, and I want to annotate that EPUB file. there is, however.
Like with, ours, the list of requirements, and this is the requirements the specification has to meet.
And I'm trying to remember if
I don't know if it made it in here.
in the document itself, because of just the nature of how EPUB works, it's not in the UCR document, but it's in the actual specification itself.
There's a section on reading system behavior and what the reading systems are meant to do because some of these.
requirements.
And maybe a good example isthe spec has to require supporting for highlight colors and styles. This is also, in the end, an expectation for the reading system to say that it also must be able to support colors and styles.
And we have kind of the same thing in AHRQ.
document as well, where there's I must be able to create accessible content.
And then the authoring tools reflection of that is.
The authoring tool must have the features.
And the output to create
accessible content.
I was looking at these action types that Evelyn so nicely.
Nicely added.
Because I think for us, in the annotation document, it just says, as a user, as a user, as a user.
I do think for us,
There's,
And maybe we use these action types, where it's, as a creator of content, or or,
As a user, when I create content.
this frames.
And goes above, whether you're an authoring tool developer or a content creator.
Like on social media or a marketer.
Evelyn Wightman: I'm
Starting to envision a possible.
Document structure.
which is
First level sort is the tool type.
type, which is kind of the same as the content type.
we've got the
Rich text editing, video editing, audio editing.
So
list those as your top-level headings.
Next level is the action type. It's okay, if we are creating rich text in a rich text editor.
Then
And I think then you can list
Sorry, use cases for all of the relevant.
Raise.
Of those three that you created.
The creator, maintainer, and consumer.
Probably only one will be relevant at a time, but maybe not.
Sorry, I'm talking too slowly for this to come together verbally. I will sketch it.
Wendy Reid: No, it's okay.
Yeah, I think, I mean.
Our UCR document is also kind of a good place for us to explain.
I mean, we can
It can be whatever we want it to be. There's no oh, this is a UCR document, therefore it must have this format.
we can explain
you know.
our high-level tools, what are the what is an authoring tool, and what
What is, what do we consider an authoring tool's scope?
and then go into, the actions expected of those authoring tools, and then the use cases related to those actions.
And then, of course,
The end is the requirements of the tools.
in relation to those actions.
Dallon. Au: Is there anything that can be then used for the measurement of.
where the two stand, right? I think
IIhow how we can how we can segment them,like what you shared, right? I thought that would be quite nice, but then, where do we
measure how do we determine if if the authoring tools have hit a certain standard? Is it, okay, they have,
They have this number of features, or the specific features.
And
And how each of these features can support each of the roles.
Wendy Reid: So that gets into when we actually start to work on the specification itself, because we'll be using the use cases, we can then turn them into.
and the requirements. We turn them into
requirements, success criteria. success criteria was the terminology we used in ATAG 2 and WCAG 2. WCAG 3, which we're trying to align with a little bit, uses the term provisions.
And a provision contains a requirement and the methods to achieve that requirement.
We can use that formatting. We can create our own.
But then
Each of those requirements.
we then have to consider, a conformance model. And the conformance model
Is essentiallyhow do you measure?
something and whether it conforms.
And I think that's where, depending on how we segment the requirements.
It's, you know, this authoring tool meets.
X of Y requirements, and therefore is.
you know, you can do this in a lot of different ways. The WCAG3 group has been really wrestling with this, where it's, you know, is this a percentage of a whole? Is this a they have, this levels model right now.
They have things separated intocore and supplemental.
There's a lot of different ways to slice and dice.
the requirements.
into something that can be measurable. And I think, one of the struggles right now is knowing, what's the best way to do that? What we know with ATAG.
IsATAG 2 is not well adopted.
And
Some of that reason is probably due to its structure and how hard it might have been to,
measure the success or report on the success.
that might be a consideration for us, is how do we make
Conformance to ATAG 3.
Measurable or easier to ascertain.
or easier, maybe not easier to achieve, that's probably not the right terminology, but, achievable.
In WCAG, we're talking about how do we almost make the structure encouraging?
to be better.
Jutta Treviranus: Yeah, another part of it is, who is it, in fact?
requiring or who is accountable to it and very large companies that.
Yeah, there's a reluctance to move very, very big groups that need to comply.
So we have a
Yeah. And in terms of Wcag, there is a whole accessibility, evaluation and repair industry that is.
who are devoted to actually ensuring that there's compliance, as we're so it's, it's a different ecosystem completely, when what we're asking is.
the the large companies that are developing the authoring tools to comply.
So I I think.
Jutta Treviranus: the that's that's something that we need to recognize as well, that it's not there's a specific framework for accessibility guidance within,
way. But certainly the reason why user agents and authoring tools, guidelines are not quite as successful is that that power dynamics. So.
I'm not sure if there's a way we can grapple with that, but I think we do need to be cognizant of it.
Jutta Treviranus: It requires a whole other compliance infrastructure. What's that? Sorry.
Dallon. Au: Sorry, can I understand more about the
Sorry, sorry, sorry. I was just saying whether I could understand more about the power dynamics that we kind of need to work with.
Wendy Reid: Oh, I mean, the biggest one is
size of companies, right? So, a lot of the tools that we're talking about, there's a big range, going from, the thing that I'm we're literally looking at right now with, we're using Google Docs. Google
is a massive producer of authoring tools. Google Docs, Google Drive, that's an authoring tool.
Potentially, now, Google Docs, for example, does have a lot of accessibility features, and so
To mean to, conform to ATAG.
They may have a little bit of work to do. They may have a lot of work to do. We haven't obviously — I haven't done an assessment.
But for them, they have a huge responsibility. And if ATAG were to become, say, I think that the big power dynamic right now is that WCAG is enshrined in a lot of international law, and so there's an obligation for a lot of companies to conform to it, but ATAG is not.
And so.
That'sa barrier. There's a power struggle there.
Jutta Treviranus: Yeah, and with WCAG, it's the consumer. So it's not the large company that bears the responsibility, the creator of the content. So it's easy for the company to push.
Evelyn Wightman: Questions:
Would it be ok if I went away and tried to synthesize what’s here already into a draft structure? (Or possibly a couple structure options?)
Is it ok if I point AI at this document to assist with the above? (Not a requirement for 1, but may help)
Jutta Treviranus: it towards
It isn't the responsibility of the company, so they're not going to oppose it quite as much. And of course, the fact that there's WCAG and its legislation means that you have an industry that can make their living out of.
ensuring that WCAG is complied to. And yeah, so it's a very, very different power dynamic.
Wendy Reid: Now, the power dynamic is shifting with, ATAG in the latest version of EN301549, ATAG gets called out, but I think it does in the old version too, but even more so now, called out by name.
Dallon. Au: I see.
Wendy Reid: And parts of it are arepulled into.
Into the document, but,
Yeah, ATAG asks more than WCAG does, at least of authoring tools, which is kind of the point.
Umm, we're almost at the end of the hour.
So.
let me experiment a little bit with, structuring
This with the different action types just to see.
I kind of want to play out Evelyn's idea around this cascade structure. So I'll give that a go.
And we can talk about that next week and see.
See if it
It helps. I think it will. Ithe idea of
helpful for us, especially in the future, working on the document, too, so
Jutta Treviranus: Yeah, it's more of an action than it is these categories of roles, right?
Dallon. Au: Yeah, thank you, thank you so much. I think I'll also look through into the document and
at least try to get to speed on things so I can see how else I can contribute.
And I thought that would be quite nice. I mean.
I I'm generally pretty new in this space.
I mean, for me, I'm a user, I'm a screen reader user myself, but I'm quite new in the space of accessibility. I guess maybe about 2
two years.
And because we're
Jutta Treviranus: We need new people. This is great that you're here.
Dallon. Au: Where I'm from, we don't have any legislation to say that we need to follow very strictly on WCAG or any accessibility standards, so some of these things that you're sharing is.
Wendy Reid: Replying to "Questions: Would it be ok if I went away and trie":
Yes and yes 🙂
Dallon. Au: It's it's true sometimes where.
whereas where there's no where there's no guidelines, or where there's no, somebody to enforce that this has to be done, then, oftentimes people may have quite a bit of pushback. So, I'm very excited to see how I can contribute in this area, and also.
Wendy Reid: Replying to "Questions: Would it be ok if I went away and trie":
If you’d like to make new tabs in the document and play around, go for it!
Evelyn Wightman:👍
Dallon. Au: To learn more from all of you here. Yeah.
Wendy Reid: Yeah, we're so glad to have you. It's always exciting when new people join, and all levels of experience welcome because all levels of experience bring different perspectives.
Dallon. Au: Right. Thank you.
Wendy Reid: All right. why don't we I think we're good for today. so and Evelyn, yeah, if you want to try and take a crack at the
Add a draft as well, feel free to make your own tab, and
And play around.
And I'll do some as well. And then we can talk about that next week.
Have a great rest of your day, everyone. Have a good weekend. We'll talk next week.