Meeting Minutes
Wendy Reid: I think getting out of the content for a second, what do people think about this structure for the document? Because this was part of the discussion last week, was, you know.
We have this big document.
We have a lot of use cases and we use cases and requirements.
And they cover a lot of different surfaces. How do we structure?
how do we structure the information so that it's I mean, mostly for us, more than anything, functional, but
Also, you know, readable for other people as well.
What do people think?
I think with the sheer amount of content, we're still it's still really hard to parse a little bit, and it's not
the format's fault. It's just because we have so many use cases.
Miriam Fukushima: I think one of the problems is I would personally prefer it in kind of like a database structure.
where you could cross reference stuff, and then just filter and see it out of different perspectives, if you have the use case, and for example, you click creator, and then you have your eye out of the perspective of the creator. And.
the metadata out of the perspective of the creator, or you click the teacher and then have it in from the teacher's perspective, or you click Ui and then have Ui in different fields, or something like that
What makes it a bit overwhelming is the linear structure, even though it's interconnected.
Evelyn Wightman: So the first draft of this had
A lot of numbers and like.
1.3 dot whatever, which I stripped out of here for Google Docs because it doesn't.
Google Docs doesn't support automatic renumbering, so as soon as we edit anything, it's wrecked.
But I think if we had that, it would support that sort of cross-linkage and
Nonlinear viewing if you so desire.
But even just jumping within the document.
Wendy Reid: I wonder too, Miriam, to your point.
There's probably almost like a tagging system that we could have, where
a use case
Especially like a high level
use I mean, it's kind of hard, because some I think some use cases are kind of,
And I would like to get to as many examples of these as possible where they are universal.
You know, authoring tools must be accessible to the author.
But then,
There are cases where it's going to be, maybe this is an education-specific use case, or a
development
Specific use case, or
language support or there's like a lot of different ways to cut it.
We could
I'm trying to think of how to do this. We could switch this over because you're right in that trying to view it in the linear format is really challenging.
We could switch this over to
a table, a Google Sheet or something, and then we can kind of do a little bit more of that tagging.
Or at least the ability to, like, do columns with filters and different data views.
Because maybe that's at least a little bit part of the challenge of review right now.
How many pages is this, I think?
15. So, it's a lot of content.
Shivaji Kumar: So
Probably, you know, not at this stage, but once we have sort of.
finalized this document.
It would
If you put it into HTML, then it would allow us all the functionalities that we've been talking about, right? We can jump around, and we can do all kinds of things for a non-linear view.
Wendy Reid: I mean, yeah, that's the other option, would be to structure this, or, like, move this over to, like, an HTML document and use
You know, ordered lists and
And all of the all of the benefits of the web platform.
Evelyn Wightman: If it's in, like, proper database.
I think that makes it potentially difficult to edit, but we can.
From there, spit out whatever sort of.
Format, like a document that could be.
Shown in HTML and cross-linked or
Just.
numbered or whatever.
Like there are working format and the output format do not need to be the same.
Wendy Reid: Yeah, exactly.
Shivaji Kumar: Yeah.
Wendy Reid: In the end, so if we publish this as a community group report, it'll be in.
W3C HTML format, like other documents that you've seen.
and in that case, I mean.
There are groups within W3C that have done
Slightly more creative things than just
Text.
with headings and all of that. There's nothing telling us that we can't
do that, as long as it's, you know, readable and accessible and meets all of the other requirements. So if we do want to have something like tagging and filtering, within the document, we can absolutely do that.
I do think,
it might help, at least temporarily, as we're trying to because, like, the one big thing I would like to do is to take, like
The giant list like this.
You know, the creator and distill it down into it's like.
you know, what
what use case is common to the social media user and the student and the.
technical writer.
Just as an example. I think a lot of these have a lot of overlap with each other.
for the final version of the document. But the best way to do that might be
Moving this over into, like, a table.
And then you can kind of, like, filter and say, like, oh, these are all similar. They get tagged as similar.
It's a bit of like data, data processing.
Does that make sense or?
Charles Hall: Having a language / terminology issue.
Use case (in my UX experience is a scenario or task, like: order food; or checkout).
What is listed here as use cases are user stories which are following the user story format.
For WCAG3, I created a positioning doc on why job stories are better than user stories. Then we as a group created job stories for stakeholders.
The job story format is:
When __________ (situation), I want to __________ (motivation), so I can __________ (expectation).
This removes the identification of the role or persona – allowing it to more inclusive.
Do we need to always identify the role?
Evelyn Wightman:👀
Evelyn Wightman: I think it makes sense.
I'm trying to think about the limitations of table format and whether there's going to be anything that's not just
Easily too degradable.
Miriam Fukushima: Yeah, I was also thinking if a table like, tables can easily get overwhelming in itself if the structure is not, like, 2D. and it also
Horrible to navigate.
So
Well, in my head it's a 3D graphic. That's kind of like where you have like a basic schematic of what a general authoring tool could be. And then.
Kind of like the different.
areas, where in my head I have sorted, okay, for UI, I have these and these points, and if I would click AI, I could find, UI, I would find.
the different points for it. If I would click the little settings buttons, I would find all the ATAG points that concern settings and metadata and whatnot. But that's a nice widget, nice ATMA.
Jutta Treviranus: Replying to "Having a language / terminology issue. Use case (":
Agree, organize by authoring related functions
Miriam Fukushima: HTML, like
fun project to do if you want to maybe do something for, applying ATAG and make it more accessible later.
I was thinking that maybe a tree.
More like a, like a tree network might be.
A thing to think about where we, have, like, the overall.
a very simplified.
workflow of using an authoring tool.
Like, you have you start your authoring tool, you have your
you set up settings, you have your you start the content you want to author, you edit the content, you finish the content, you export the content, and then
In these steps, if we take that as columns or as tree points.
We sort and,
the different things to when in the workflow they apply.
And then we could also cross cross reference like if it's a tree. And if you have all the possible, for example, people that start up an authoring tool, and then you have as next step. The settings you do for setup.
And have different things, like accessibility settings, accessibility documentation and stuff, that's very general, but for teachers or whatever, don't have all the points in in hand,
There are some extra things, so we could
draw,
Well, it's a bit hard to explain. I mean, we can draw up a quick.
Wendy Reid: I can see it in my head. Charles, to your point in the chat about the job stories.
I think
That's kind of what we were trying to get to with this concept of these like.
High level roles?
Where there's, like, the creator of the content.
Charles Hall: Right. But the the the reason I bring it up. It's because in in talking about organizing that document, organizing the information.
One of the things that I'm I'm already observing, looking at this, list for the first time, is
a high degree of overlap or potential overlap. So there'll be two bullets that are nearly identical, and the only difference is the who.
So, to help better organize that content.
An alternate format might help. Like
What we did in the job stories,
for stakeholders for WCAG3. So this was, like, silver work back in the day, like, 2018, 2019.
the these are all written in the user story template.
If we instead used the job story template.
then we don't have to continuously identify the who.
And some of these will then end up getting combined, because the focus is on the task that needs to be done versus the who is doing the task.
We could find another way to tag them so that the who that we know will be doing that task is also identified, but it just it reduces the amount of overall information that then needs to be organized.
Jutta Treviranus: Yeah, and I'm wondering, given, what do we need to do to support the creation of a working group and to inform the working group overall? This document is going to keep evolving, right?
there are new roles, functions, etc. It's a quick so, I'm wondering it's not going to be complete, and it certainly will be added to as we go through the other.
tasks that we need to do in order to arrive at the next ATAG, etc.
the I mean, we could work on this for
Many, many, many meetings to come, and I'm just wondering, in terms of prioritization, like prioritizing, or, sorry, too early, looking at the priorities we have and the tasks that we need to do as a community group.
to support the effort. What are the other things that we need to do?
Wendy Reid: Good question. I mean, I think the other major area for us.
of concern is
Essentially, the research side of it, I think we had, like, we have this list of, kind of.
Growing, growing questions.
Umm around like.
Terminology, so the new terminology that's been created or is being created over time.
the accessibility this came up a couple times, like, the accessibility of technical languages or syntaxes and the authoring tools that produce them, so I think we have a lot of open questions around.
LaTeX, MathML, ChemML production and the authoring tools for that and how to make those successful.
Jutta Treviranus: We have the question of the what is what is the influence of AI on this entire space? We have the question of what the fuzzy boundaries between, or the the sort of breakdown of the classification of what is user agent, what is authoring tool, what is, content.
And I think one really critical issue is what happens to user agents, since there is this gap in the way.
work at the moment, how much of the overlap between authoring and user agent, and things like Agentic, or interfaces that are derived through and I mean, there's.
There's quite a bit here that we need to delve into.
Wendy Reid: Yeah, this last question is probably one of the bigger ones, the new boundaries between the authoring tool, the content, and the user agent that presents the content.
and then also considering assistive technologies and agents outside of the user agent, so Agentic experiences.
Charles Hall: Does, does that.
concern that was just raised mean that we have clear boundaries between the scope of the working group and the community group.
Are are we shifting now into the
traditional incubation role to just focus on the things that will be needed.
Miriam Fukushima: Replying to "Having a language / terminology issue. Use case (":
Just put a schematic at the end of Structured draft
Wendy Reid: Yeah, the community group will be the incubator and the research. And like for now, because there is no working group.
That's why we started undertaking the use case work.
Charles Hall: Yep, understood. So given that, back to the question that was on the table about the structure of the document.
That makes me much more in favor of a traditional ordered list of sections, because then everything can be cited by the number that it is.
Wendy Reid: All right.
And so then I guess the because it's easy enough for me to move things over into, like, an HTML format document.
I think the question raised by the draft is, what did those
sections that section structure, what does that look like? Because this format that we talked about last week, that Evelyn, like.
created.
is essentially following this pattern of.
at, like
Maybe we said tool type, but, like, action.
the type of action and the use cases and requirements associated with that action.
Is that a good structure? Do we need do we want to go back to things like the original structure was essentially use cases.
Authoring tool requirements.
And it was pretty loose after that.
We can go with, like, the user taxonomy.
We can try different ones and see which one we like best, maybe.
Sorry for scrolling.
Miriam, that was so fast.
All right. Miriam has this authoring workflow structure.
It's essentially five columns starting with, at the farthest point, the who. So it's the user type.
Startup, so I guess, like, setup
Settings, the content creation, and editing of existing content.
Miriam Fukushima: And then we like, I didn't think long about the different.
steps of what a generalized workflow could look like. But we also have the output and the export, for example.
where we have points is that, for example, accessibility information must be kept. This would go into export, probably. Something like that. And
would be for all authoring types that have a certain format type.
like, PDF or, Word documents or whatever.
Various authoring tools that just give like an output in the sense of in the tool and it never leaves the tool, don't need to be connected to that.
certain step.
So we could have, we could list certain things without having to list them double under every.
combination of
Things like whether it's a teacher or.
A programmer.
If it's a point that goes for
the authoring tools that both use, and they're interconnected. But if it's something teacher specific, then it's not connected to.
the development.
authoring tools.
If that's kind of clear. In my head, it's very clear, but I don't know if I can explain it right.
Wendy Reid: Thank you.
I know, I have a similar
similar kind of structure in my head where I'm imagining kind of this like.
Tree
It's almost like a family tree diagram of like you start at the very top.
And there's
kind of
whatever there's, like, a set of, like, the first layer of actions, and then it just kind of cascades down from that, because, like, your first action is
Creating content.
Then by necessity, there are like further actions.
So, like, creating content.
And you could say, like, adding event, like, all the different things that go into creation of content.
Miriam Fukushima: Yeah, for me, the, like, the one sentence we put in use case is, like, going through one, like, tracing one line through this network.
Wendy Reid: Mm-hmm.
Yeah, and I can imagine like you could, the way it's structured, you can like trace different lines.
Through it.
for different roles, or even just, like, different workflows. Because, like, your editing workflow might be different than your authoring workflow. Your
remediation workflow.
Auditing workflow.
Evelyn Wightman: I'm trying to grasp the tree. As you go down layers, are you
Getting more specific about the current action you were taking or are you?
doing subsequent actions in a workflow.
Miriam Fukushima: For me, it's both, because, like, in one on one hand, it's subsequent, because you go through the workflow, you, like, you start your tool, you get your talk content, and it doesn't matter if it's, like, actually a person really creating the content, or a person using the tool and creating fake content to test the tool.
like, not really content to actually publish, but content to just test and try out the tool, to evaluate it, or whatever, or make a buying decision.
So it's not, necessarily that it's,
No, I lost my yeah. And but by combining, like, every step you go further, obviously you combine combinations, and therefore it gets very specific. Like, if you start with who and choose the teacher, and then, go to the starter and start up, for example, a quiz.
authoring tool, then you're already in a more specific.
In like setup, then just saying, okay, it's an authoring tool by.
person XY. And if you then go into the settings and say, okay, Chris,
a setup needs to have accessibility settings. So I can set dark mode for my questions, for example. Then you get even more specific, and then you have the content creation. Where's you have all the things. Okay, I need to.
go get in, put in the questions, the answers, and need to format it and whatnot. but if I put, pictures in, they need alt text and whatsoever, and then, edit existing content. I need to, for example, import the.
the question stack, and, change it, or correct typos, or whatsoever, or answers if they were wrong and I need to export it, for example, as a link for my students to take the quiz.
So the further you go along the workflow, you get more and more specific.
But by, and by choosing a certain path, you create that specific use case.
But at any point you could, choose different nodes to, get to different ATAG requirements.
That also apply to the previous.
the things you have chosen, so you are still, if you choose the teacher in the beginning, you are still in the use cases of teachers.
And everything that applies to the things we have collected for teachers.
At least that's how I envision it, but
Now it's in my head.
Charles Hall: Is everyone familiar with the FAST?
The audience is creators of web technologies.
This conversation makes me feel like WAI needs something like the FAST for all of us working on accessibility standards. To have template models for how to write and how to organize what is written based on the needs of the audience and inheritors.
An individual CG should not have to re-invent document organization.
Charles Hall: I feel like that could work if we also had a
Research lens on getting direct feedback from each one of those roles.
Like, what are the tasks that you actually do?
What are the tasks that
that
are a direct result of the task you just did.
Wendy Reid: I realize that it's not a linear diagram, it's more of a
It's kind of like a dandelion. I'm sure there's a name for this type of document.
Charles Hall: Yeah, it's not even a tree because choose your own adventure.
Wendy Reid: It's like I'm sorry.
It's like adding an image, there's spiky actions. Sorry, I'm holding up a picture.
of my really bad handwriting. but, like, the core action of adding an image, there's implicit things that spike off of it. So, like, alt text, extended description.
metadata, caption.
They're not all necessary, but they all are like implicit subsequent actions.
Of adding an image.
adding a
Adding a video, adding audio, you know, you have to captions,
Transcript.
So there's, like, these
Everything has this kind of, like, burst around it of potential actions, and so, like, no authoring process is linear.
But everything has changed.
I'm
It's in my head. I can see it. It's like a giant star. It looks like fireworks.
Charles Hall: Pretty hard to make a three-dimensional document, though.
Mitchell Evan: What I'm hearing is that it's. What I'm hearing is that it's useful to talk about the kinds of activities that take place in an authoring tool, but maybe workflow is not the title for it because that implies the word workflow implies linear process.
Evelyn Wightman: Replying to "Is everyone familiar with the FAST? The audience ":
Haven’t seen FAST but +1 on we shouldn’t have to re-invent document organization
Ned Zimmerman:👍
Wendy Reid: Yeah. I think workflow
Maybe that's what's getting if anything, that's,
Let me stop sharing for a second. That's what makes this as hard as it does, because I think
No authoring process regardless of where you're entering it from is linear.
If you are the creator of content.
you have all these actions. If you are an editor of content, you have all these actions, and depending on the actions you take, further actions are kind of opened up.
If you're even the auditor of content, like, if you're, if you're just looking at testing, like, testing content.
or a tool, you know.
I mean, anyone who's done, like, accessibility auditing can tell you, like, you find one thing, and then you end up down, like, a wormhole of finding six other things.
Miriam Fukushima: Yeah, why it's kind of linear in my head is for the simple reason that,
Like, for example, if you have the, okay, the WHO
And then the startup and the settings. It doesn't mean you can't skip.
a thing, a step in the workflow, because you probably only set up your application once, and then from then on you use it. And then it also doesn't mean you can't loop.
endlessly between the steps, but, in taking basically the most basic categories of a workflow that can ever be.
It kind of gives it back this table structure that people, if they would look at the possibilities, could easily categorize where am I now in what I'm doing or what I have to evaluate.
and concentrate on that column.
And go from there.
but still have kind of an overview of everything.
and kind of find a middle ground between, okay, I have, like, kind of these, I can go from your fireworks to one, like, it's a bit like the Wikipedia network,
which, is very hard to overview. Give it kind of a table structure, but still have the interconnectivity of, getting.
Jutta Treviranus: Should we go back to the questions of how this will be used? What about creating building blocks of authoring functions that can be organized based on the use.
Charles Hall: Similar to the ARRM (accessibility roles and responsibilities matrix)?
Miriam Fukushima: back and forth, and not having to repeat single notes if they appear once in a step. I can reference all other notes to it, but I don't have to.
Write it double under every step or whatever.
Charles Hall: Replying to "Should we go back to the questions of how this wil":
Like Lego?
Miriam Fukushima: Kind of, that's
My idea behind it.
Evelyn Wightman: My thought is cool.
partly being articulated in chat here.
I'm seeing two things that maybe we could get rid of.
One, do we need to be concerned with workflows of how actions connect to each other or are we?
Just looking at.
I am doing this action right now. What are the requirements for doing that?
And.
Do we need to know who I am? Like, what my role is? Or do we only need to know what I am trying to accomplish?
Because I think the most important part is.
The requirements and the use cases and user stories, job stories, whatever format we're using are, like, a way to get to them.
Mitchell Evan: I think those are great questions. My take, quick take, is that the answer is no, you don't need it. Who does it? No, you don't need the
I'll be overview of a process, however. as an as an explanatory thing.
Jutta Treviranus: Replying to "Should we go back to the questions of how this wil":
Legos only have two connection points.
Mitchell Evan: Putting these requirements in human terms and familiar terms with examples and work. Those is help. It could be quite helpful for understanding. But no, I don't think they're kind of essential to the require to articulating the requirements.
Jutta Treviranus: Replying to "Should we go back to the questions of how this wil":
this would have many.
Miriam Fukushima: Yeah, I also think, like, from a hierarchy point of view, there's no, like
Mm-hmm.
like, they are all on the same level. If I use a tool, I use a tool. Period.
But like a kind of pre-categorization could be helpful to not have it all one level.
but in, like, backs of
the kind of,
categories.
Evelyn Wightman: Replying to "Should we go back to the questions of how this wil":
Say more? Interested in this direction but not quite picturing it
Wendy Reid: I'm taking that I
Idea of the like.
the firework diagram. I'm sure there's a proper name for this and I'm just, I don't know it.
I do think there is, like, yeah, there's the hierarchy in the columns, because essentially there is
There's a part of this that is, like, who is doing the action.
And who does not necessarily need to be a person, but it does there is, like, an entity doing the action.
There's the process being started and what tools are being used for that process.
There's the creation or editing of content.
And then
Based on what
at creation or editing action is being done or what content is being created.
there's further needs that get created. It's like that, like, if you're at an image, you must therefore have alt text, you know, etc, and that branches off.
And then there's the metadata and settings for the content, so the kind of roundup.
So everything kind of cascades in this, like
It does, like
Start with
a simple point, but then it kind of like branches out.
which might be easiest to display in something like a table, because then we can have, like, you know.
Additional content be populated.
Charles Hall: Yeah, I think
All of these organizational methods have merit. I think they change based on that core question that I'm not the only one that raised of.
Jutta Treviranus: Replying to "Should we go back to the questions of how this wil":
There will be people that want to use the blocks for workflow, others for creating a user requirements description, etc.
Charles Hall: Possibly removing the who.
Right, so if we took if we took roll out of it entirely, then we narrow the information that has to be organized this way.
But because we've already done the work and identified the roles that do some of these tasks, it's still useful information, which I would propose is a secondary document, a supplement somehow that's similar to the ARM.
The roles and responsibilities matrix.
So we take the task that's been identified in document one and put it into a matrix to say the roles that are relevant to this task.
Mitchell Evan: Replying to "Should we go back to the questions of how this wil":
+1 to roles and responsibilities as supporting info
Wendy Reid: Yeah, I like that. I think because.
I mean, as we kind of keep identifying, even though the roles, like
the who part is not unimportant. Realistically, like, there's
It's a Venn diagram with three parts that overlap quite heavily.
Whether you're the creator, the editor, or the the creator, the maintainer, or the,
reviewer, consumer, I think is what we called it. there's tons of overlap, and so, like, overlap to the point where maybe it doesn't quite matter, at least not initially.
What matters are the processes and what they.
What they create and what is necessitated by their creation.
I think I have an idea for what to do.
Mitchell Evan: yeah, so plus one to, what Charles said, you know, that it's
Valuable supporting information. And more recent too.
Not pay for roles to an afterthought, however, which is that. This group's own process of coming up with requirements would do well to remember all of those roles as we keep asking, do we cover.
of, you know, human activities that people actually do.
Wendy Reid: Mm-hmm.
Yeah, absolutely.
Alright, I will take a crack at.
Some restructuring.
And I'll try and do it in HTML document just says then we can like reference things and and link and we have numbered sections and all that nice stuff.
I won't be here next week, so Ned is gonna be chairing for us. but Ned, I'll share all the information ahead of time so you have it.
It's a perfect task because I'm going to be on a plane all day Sunday, so I've got nothing better to do than work on this.
All right. I think that's a good place to end for today. I hope everyone has a good weekend and we will talk to you all next week.