Meeting Minutes
Lisa Liskovoi: So for today, we were going to discuss ATAG section A just kind of guideline by guideline and see where it makes sense to inject some new considerations. Think about how AI might factor into those criteria or change those guidelines and criteria
So
I was thinking we could do this guideline by guideline and then kind of get into the success criteria as needed, but does anybody have a different approach that they would like to take?
Okay.
Great. Let's let's dive right in then.
So guideline A, I'm just going to post it in the chat.
Actually, I'll post the first principle as well for reference.
Lisa Liskovoi: Principle A.1: Authoring tool user interfaces follow applicable accessibility guidelines
Guideline A.1.1: (For the authoring tool user interface) Ensure that web-based functionality is accessible. [Implementing A.1.1]
Lisa Liskovoi: So the
The first principle is authoring tool user interfaces follow applicable accessibility guidelines. And the first guideline for that is ensure that web-based functionality is accessible. And actually, I think we can do probably guideline
0.1, point one and point one point two because they effectively are talking about the same thing, just web-based versus non-web-based. So guideline 8.1.2 is the same requirement, but for non web-based ensure that non-web-based functionality is accessible. So I'll
Lisa Liskovoi: Guideline A.1.2: (For the authoring tool user interface) Ensure that non-web-based functionality is accessible. [Implementing A.1.2]
Charles Hall: I was just gonna say that the obvious change that I see is version
It references WCAG 2.
Lisa Liskovoi: Okay, yeah, that makes sense.
Miriam Fukushima: Yeah, I was thinking about, before the actual guideline, the part about the notes and before that point three developer control says that it's not meant for third parties and doesn't apply to user modifications, but later on, which comes later is A3.
The user preferences and stuff, so maybe we should like kind of edit the phrasing of that to
Like have it a bit broader and say, okay, but third party software and plugins. But user preferences will be explained and
later in A3 or something
Lisa Liskovoi: That makes sense to me. And do you think it's worthwhile going through the note, like all of the notes themselves before we jump into the criteria? There might be some more stuff in there that we want to tackle.
Miriam Fukushima: For the notes, I was fine with the rest, but maybe other people have other points.
Lisa Liskovoi: Okay.
I'll just paste them in the chat in case anybody wants to take a look at them.
Lisa Liskovoi: Scope of "authoring tool user interface": The Part A success criteria apply to all aspects of the authoring tool user interface that are concerned with producing the "included" web content technologies. This includes views of the web content being edited and features that are independent of the content being edited (e.g. menus, button bars, status bars, user preferences, documentation).
Lisa Liskovoi: https://www.w3.org/TR/ATAG20/#guidelines
Lisa Liskovoi: Okay, should we move on to the second guideline?
Yeah, yeah, Mary, go ahead.
Miriam Fukushima: So, last time we said we should also think about how AI plays into each one of these. And if we want to include them here or do a separate part of about AI. And I was just thinking that if we say, okay.
Web-based functionality or non-web-based functionality needs to be accessible that if we factor in AI and how AI is structured, it's usually a prompt, and then the result of a prompt which could be interpreted as content itself, but
Could also be the web interface because
The AI is authoring content, but the result of the AI could still be in the scope of
what the web
what the interface of authoring content is. So there, I feel like maybe it needs a part on
maybe an 81.3 or something that kind of clears a bit the line between what is actually the edit interface in context of AI.
Jutta Treviranus: Yeah, I was going in the same direction that Miriam was going because of course, it's it is a conversation to some or it's a back and forth, so there's
the authoring at the point of
request, or there's the automatic authoring within AI, and the monitoring of that, and yeah, so it's a it becomes a much more complex authoring process.
And what how do we define I mean, I think
bringing in AI
there seems to need to be a definition as well of what do we call authoring, so it would be good to revisit what is an authoring tool, or what is the authoring process.
Wendy Reid: Okay. I agree as well. I also think there's an interesting challenge in a lot of the, at least the current kind of AI tools where there's your chat interface
interaction, but then some also have, I know I believe Chat Gpt does this where you can also work with it in a sort of canvas
Interface where you can actually do live editing. Or it's like a little bit more interactive than chat. So there's almost these like different levels of interaction that are introduced by tools that
further blur the line between the strictly authoring interface and the content itself
So I think I agree, I think, with both Miriam and Jutta that we need a 1.3 to kind of clarify the boundaries of content and authoring
interface
Miriam Fukushima: Yeah, I also think that for the authoring interface, a lot of AI display or have the option to display their thought process. So that should also be accessible. And it's kind of part of the around the editing part
not about the actual content, but
part of the yeah
Editing interface
Lisa Liskovoi: So not just the final output, but also transparency around the actual process for creating that output.
Miriam Fukushima: Yep, because you kind of need to access the thought process to know how you do your next request and stuff, but it's not the actual content. If you tell the AI to edit a PDF, then the PDF is the content, but the thought process of the AI going through the PDF is then part I would consider to the all around editing interface where there is a drop down or an accordion or whatsoever where you can access that
thought process and it's meta information for the author, not part of the PDF and the actual content.
Jutta Treviranus: Agreed, it is part of the authoring process
Abhinav Kannan: And Zoom as a tool has a canvas, too! But its AI features are separate afaik ...
Wendy Reid: some interfaces also have you can almost when you're reading the output of the thinking process, you can almost interrupt it or add additional context. I know Claude has this thing where you can kind of they call it like slash by the way
Or BTW, and it's like you can actually inject
Information mid prompt.
So like while it's thinking you might see something in its thought process that's incorrect or needs additional nuance, and you can actually provide that, but only if only if you can actually see the
or interact with the thought process.
Shivaji Kumar: Yeah, so, you know, I agree 100% with what you're whatever
has been said so far regarding AI.
But I'm wondering
How far can we go to incorporate AI into these
into our workflow right now.
You know, there is no end to it. It feels to me.
So, where do we stop?
Or should we take AI wholesale on board and go with it?
I don't have an answer.
Lisa Liskovoi: Can you explain a little bit what you mean by integrating it into our workflow right now?
Shivaji Kumar: Yes so what
within the ATAG,
guidelines here.
how much of AI-related stuff we need to cover?
Or should that be part of a totally different
group. yes, we need to give a nod to AI.
But can be really integrated.
Jutta Treviranus: Given that AI is used to create more than 50% of Web content.
Shivaji Kumar: AI and everything that we're talking about here.
I don't have an answer to that question, but I think it is worth
um, considering here.
Would that not take us away from our main focus?
Jutta Treviranus: Can I make a comment? Given that well over 50% of web content is now created,
using AI, I think it's it's
integral to considering authoring.
Lisa Liskovoi: Yeah, and I think the boundary is just anywhere where AI would impact authoring specifically, we should consider it. That would be
Charles Hall: Over 50%? Gross
Lisa Liskovoi: My understanding, but I'd love to hear other people's thoughts.
Miriam Fukushima: Yeah, I would also say it's very important that we also define the boundaries and like really detail, like lay it out because like AI can be part, even if it's not now, but in the future it can be part of every authoring tool
And, if not only for marketing, but
So, it can impact every
step in every workflow, and thereby also change the way we interact with the authoring tools like mostly it's about interfaces, buttons, and short descriptions. But if AI is more prominent, then it goes more to a conversational interaction
Which fundamentally changes the interface. So and that brings also new requirements for the interface
So definitely it should be part. I feel like
Shivaji Kumar: Sorry. So I so, you know, I'm looking at it more from the implement implementation perspective.
So, what we
in our document right now, we have our guidelines and implementation.
rationale and everything, so then maybe add under each
guideline
another sub-guideline about AI and
And if this is
being produced by AI,
And here is how we should be dealing with it.
Is that how we should be implementing it in our
document here.
Wendy Reid: I think
What we're getting at, and I think that this exercise will help is considering that where do, as we go through these guidelines one by one, where do they change or need further information because the interface is because
either the interface or the content has changed due to the
Influence of AI. I think there's gonna be several of these that do not need to change or be
fully amended because
even with an AI tool, the experience is the same or the process is the same. It's really more
the cases where actually, like, things have changed quite a bit.
And
Or, like, that the interface or the interaction is so completely different that we need to factor this in.
But there's probably going to be cases where we don't have to change anything at all because it's totally fine.
Jutta Treviranus: AI and human authoring are not easily separable.
Charles Hall:😮💨
Lisa Liskovoi: Just adding a section on AI for every section might be complicated because it's going to be so much more entangled than just, is it using AI? Is it not using AI?
Abhinav Kannan: Yeah, thank you so much. This is interesting.
I think
there is a spectrum. On one hand, you have we can go guideline by guideline, like Lisa said the tone of the meeting and the stuff. We can go guideline by guideline and think about, okay, where does
Um, to what extent can we think about
AI changing the rules.
Or AI playing an influence in the rules.
So that is one end of the spectrum, and on the other end of the spectrum,
We have
Uh, we can think about how AI can completely overhaul overhaul the
authoring tool accessibility guidelines from the from the very top.
Or we could do somewhere in between. I know we are in this middle place.
But I'm just thinking about, since we are thinking about what kind of
boundaries we should set with respect to
Um, with respect to modifying or changing updating the guidelines,
Uh, I would say I would think that for some guidelines, it is
It is very concrete. For example, uh
Text-based search, right? Text-based search is one of the guidelines. We can
In such a case, we can we see a clear
way to make
To add AI as a sub.
Uh, as a way to modify the guideline. Within that guideline itself, instead of
Instead of cross
Instead of across the whole list.
But in some cases, we can there is a bit of a there's a bit of fuzziness. So I think this is one
One way to look at how we could I think we should talk about boundaries first.
How can we
Uh, how can we not get carried away in discussing AI and the ways in which it can affect the guidelines? Because that is a
that can lead us in many, many different directions, so I think we should set that tone.
Charles Hall: That's a good segue, because the point that I got on cue to make is part of what Abhinav just mentioned is in the general approach
I think
My my brain works
in trying to conserve energy. So I look at this problem that we're trying to solve from what's the one place
AI can be part of the guideline so that it cascades to everything versus trying to find a unique way to wedge it into individual things.
And the natural conclusion I immediately draw is the definition of content itself, which we also have to address anyway, because the current definition of content in both a tag and WCAG
Is that content includes code and markup
We have to decide if we want that to persist, and if we do, then
like Wendy's point earlier on the different interfaces that AI provides
That's moot because all of it is content in the current definition
So I think if we fix the definition first, it cascades to cover the things that we want it to cover.
Jutta Treviranus: Um, no, well, I just a very quick comment, which may
complicate this, but I think there's reason, and I know it's beyond this group, to question the distinction between
authoring content and browser, so that those because I think that has evolved quite significantly as well. And
Um, but that, of course, is a larger conversation.
Lisa Liskovoi: Does anyone happen to know if the UAAG, sorry, the User Content Accessibility Guidelines or user agent accessibility guidelines group is looking at AI as well?
Shawn: There's yeah, there's not a UAAG group right now. So, there is consideration for how that is addressed in so the old WCAG was Web Content Accessibility Guidelines, and the new
WCAG3 is actually W3C accessibility guidelines, and the reason for that was to be able to enable to broaden the scope
of that set of guidelines. So that was the original intention, and the group is still largely focused on content.
But the browsers and authoring tools, even, are now outside the scope.
We are coordinating with them in terms of
you know, how the this the work of this group will relate.
But there's not a separate UAAG right now.
Charles Hall: UAAG is dormant
Saif Altalib: I'm thinking a new sub-section like this is clear and useful:
Guideline A.1.3: (For the authoring tool user interface) Ensure that conversational and generative AI functionality is accessible.
Miriam Fukushima: Yeah, I would say to the kind of the scope or that the problem of where to start and where to end, that for this session, I mean, we have the part A on the agenda, which is mainly just the
Editing interface, and that I feel like can be
Well, can be seen as like
Separate from the content and which probably would also help us to kind of set the scope and like break it into smaller parts. So if we just concentrate on that for this session, and then, for example, for the first guidelines say, okay, as to-dos, we have to update the references to WCAG
And also, like, include 1.2.3 for how the accessibility of editing
of the edit interface changes in
different in relevance to AI
And then just
Proceed with the next guidelines. I think that's a good scope to break it down for one session, at least in my opinion. But I would consider the defining the content then for next session and then
Before we proceed with the guidelines about the content
Abhinav Kannan: Replying to "I'm thinking a new sub-section like this is clear ...":
Great first stab!
Lisa Liskovoi: So, sorry, you're saying go through the rest of aid, then come back to definition content and then get into B.
Okay, great.
Mary Ann (MJ) Jawili: Yeah, sure, I guess I was just wondering,
So, you know the guidelines right now point to WCAG some version of it, I guess 2.0. But they're also working on WCAG 3 and I don't know exactly when it might be published, but
Saif Altalib: Replying to "I'm thinking a new sub-section like this is clear ...":
I used AI lol
Mary Ann (MJ) Jawili: I guess I'm wondering, like, what if we come up with
some
Changes to a tag that
might conflict or might conflict with WCAG 3 like worst case, I guess. Is that something that we have to consider or
worry about
Shawn: Sure, happy to. yeah, thanks for that point. It's absolutely something that we need to watch out for, so we will be coordinating closely with
the AG Working Group, and to ensure that we don't conflict.
Yeah.
Lisa Liskovoi: We can move on to guideline two. So we're getting into the perceivability, understandability and operability of the content. So principle 8.2, editing views are perceivable. And under that we have making alternative content available to authors
Ensuring that editing view presentation can be programmatically determined
and some success criteria underneath that. So I will just paste a link to that section in the chat, and if anybody wants to get us started.
Shawn: Yeah, this is a big question I have. So A1 says the tool interface should be
should follow OK, basically.
And then A2 is specifically pointing out operable, A3 is point or A2 is perceivable, A3 is operable, and A4 is understandable.
So my question is
Why do we need
um, A2, 3, and 4? Doesn't A1 cover that?
It's a question.
Miriam Fukushima: Replying to "I'm thinking a new sub-section like this is clear ...":
Guideline A.1.3: (For the authoring tool user interface) Ensure that conversational and generative AI functionality is accessible and that AI content/output can be part of the interface and make the interface change dynamically.
Abhinav Kannan:👍
Ned Zimmerman: Yeah, I mean, I think
The pieces that are in A2
Well, it's a mixed bag. It's a good question.
Um, I think there are some pieces in A2 that don't
really appear in WCAG in the same way.
Um, so
So, for example, um
editing view status indicators, right? This is the A221.
Um these are things that are specific to
the content being edited, such as, you know, spelling errors, track changes, hidden elements that
are have a bit of a different
they're not, like, just content, per se, they're sort of dynamic properties that change during the editorial process, and so I can see that there's some
extra pieces that don't really fit into the
straight WCAG guidelines that are being highlighted here.
Um but I think some of them are
Some of them are very similar, and there is some overlap. Keyboard traps, keyboard access
Um
all the keyboard-related ones in A3.1.
Um
Yeah, it's I don't know, it's a mixed it's a mixed bag. It's a good question, and maybe deserves to be dived into a little more deeply.
But others may have sometimes.
Jutta Treviranus: Yeah, I can probably yeah, I can I can clarify here. So the the intent originally was basically, when you're authoring, and certainly at the authoring process at the time, had the author's view, so the author may require a different view of the content,
So, say if you're blind, and you are creating a visual interface, you are likely to have a different view of
The content that you're creating, then what will actually be rendered on the website.
So that was the intent here. And it came out of
participants in the ATAG working group.
that that had that experience. So, the
It wasn't the final content, it was the process of authoring that
the interface needed to be accessible, so you may have
a completely different view of
the content because of your accessibility requirements.
Does that make sense? I can explain it further. I can give some more examples.
Shawn: That's great, Jutta. I was hoping you would chime in with a background.
Um, yeah, so I I great, and there are other people on the queue. I also wonder if if
I think it would be great to think about if there is a way that we can, again, simplify the guidelines themselves.
And, you know, and so we do we broadly include that in the scope of what this covers?
And describe talk about it in implementing, but yet the guidelines itself maybe can still be simplified
That to
So, it's included without having all the details.
Just an idea. Okay, good, good.
Jutta Treviranus: I agree, yeah.
Miriam Fukushima: Yeah, I partially agree with that because I still think that, especially for ATEC, it's important to
Kind of have this twofold workflow where the author needs accessibility requirements and needs to be able to make the content accessible and then the content being accessible
That, maybe you we could put like a one as kind of the overarching base requirement, and then
kind of
Highlight certain aspects that make authoring tools special compared to just the output of authoring tools, which would where we could say, okay, really important is, for example, the highlighting of statuses for the author during the process
which has nothing to do with making the content itself accessible, but it's
kind of part of the workflow
Disregarding what the content actually is
Mary Ann (MJ) Jawili: Oh, I'm just I was just typing my message in the comment, because I realize it's not anything new. I just agree with the current comments about how maybe we can we should take a look at how we can
adjust this part of the of ATAG so that we're not repeating
WCAG, and also
I mean, I think Utah brings up a really great point about that experience where a blind person might need to have a different interface, but at the end of the day, that's still like
That's still
maybe web content, and I think WCAG can still apply, so we don't we shouldn't if we can massage the text a little bit, I think we can
Have it so that we can just point to WCAG.
And not have to be so specific or go into all these details
Lisa Liskovoi: I also wonder if in cases where it is different than WCAG, it's worth just clarifying that through something like a note on the criterion to better understand how it goes beyond WCAG, or maybe there's a better place for it. But maybe when we dive into the actual specific success criteria for guideline E, we can think about how that's different than what would be covered in
Lisa Liskovoi: https://www.w3.org/TR/ATAG20/#principle_a2
Lisa Liskovoi: Principal M 8.1. So, I'm gonna put the link to A2 in the chat
And so under making alternative content available to authors, we have the 1st success criteria and text alternatives for rendered non-text content. If an editing view renders non-text content, then any programmatically associated text alternatives for the non-text content can be programmatically determined
And the second success criterion is alternatives for rendered time-based media. So if an editing view renders time-based media, then at least one of the following is true. Either there's an option to render content in an alternative format or authors have the option to preview
the time-based media in the user agent that is able to render alternatives.
Charles Hall: Move on. If I understood the historical context from Jutta, the
reason that A23 and 4 are distinct from A1 is A1 accounts for everything outside of the editing view.
the path the author has to take through the tool to get to the editing view, for example.
And if that's the case.
It's simply a matter of wordsmithing to recombine those two. We don't have to say editing view versus the rest of the tool.
Shawn: Right, that's a sorry, I don't I don't
I don't know how to raise my hand quickly. There we go, okay. then that's what I think I was yeah, that's what I was trying to say. Thanks for
Or saying it more clearly, Charles.
Can we just change the definition?
Um, so that it includes the editing view.
Again, then all that's covered in the guideline, and we can say more specific in the, you know, in implementing.
Lisa Liskovoi: But in 8.1, it says the authoring tools user interface. So I'm still not sure about how that's different.
Jutta Treviranus: Yeah, I mean, one of the other considerations is there's additional information that the author requires.
Um, that is not actually
considered content, so, for example, both the
the markup and I mean, the rationale behind the prompt, etc. So there's things that
I think when we re-merge the or
I agree to a simplification. I think that's a good idea. but then there
There are a number of things to consider that go beyond
um, what WCAG would be considering.
So an author needs more information.
then the audience of, or the consumer, or the
the user of the content itself.
Shivaji Kumar: So, um
I had a specific comment about the timing part.
Um
So, I agree with everything that's in there, you know, time extension and things like that.
But then, um
what is often missing from the implementation
Uh, in these cases is that
wherever that
timer appears?
Um, first of all, you don't know where the timer is.
Many times, people people implement it in such a way that it is
Either at the top or at the bottom of the page.
And once once someone using a screen reader actually finds where to
extend the timer
And they actually did actually do extend it.
But the, um
But their focus
then jumps either to the bottom, or top of the page, or the bottom of the page,
then they need to go back to
to their original workflow to find where they were.
So those kinds of implementations
Uh, even though they will meet time extension
success criteria, but then the effort and time
spend and just extending
the time limit, and getting back to the real workflow.
flow. That's
that causes a lot of time and effort.
So is there a way we can address that here?
Miriam Fukushima: Well, I think, the problem with whether, for example.
Editing view status indicators, and so on, whether that should be mentioned
Despite
The editing view and the interface already having to adhere to WCAG. I think a good example would be maybe if the author marks a content as, for example, in red
Let's say the author is a blind person and they mark the content in red. They need to know that they marked the content in red.
Whereas WCAG says, okay, if that red is important for
Like referencing information, it should also be marked up in another way that is not only for color. But if it's just purely decorative, it doesn't need to be. But the author
All which needs it to be marked up as red as an alternative to know when they used it or not, when they used a certain interface
Despite what the end content
Will include or not. They also need to know whether they then inserted an alternative. Like, for example, extra text or whatnot to also then make it accessible for the end user
This also should be able to be transported to the author. If it's a blind person or whatever. But I think it's important to still have certain
points
Yeah, formulated despite them technically just being covered by WCAG, but to formulate them in a way to say, Okay.
Technically, it should be covered by WCAG, but in the case of authoring tools, it needs to be stronger or whatever and then formulate the difference between how it is for an authoring tool and for the author while
needing certain accessible accessibility requirements, and then
what the difference is to actually to the content, when it's done.
Lisa Liskovoi: That's a really good point. And I think in WCAG, if somebody can correct me if I'm wrong, that there's certain exceptions where something is controlled by the user. And I'm wondering if this is a situation where something might be considered as being controlled by the user and so it would be a kind of exception, but we actually wouldn't want it to be an exception.
Yeah, Utah.
Jutta Treviranus: Yeah, I guess I have a question for Remi and Shawn, and um
given the that we're not expecting WCAG 3.0 for quite some time,
And given what we do know about
the current versions of WCAG.
how I mean
what if we yeah, what is what will be that relationship between
the two. I mean, if we're depending
completely on WCAG for
much of the technical guidance and the compliance checks and things like that.
Oh, yeah, just it's becoming quite worrisome, because it's not a
a definite thing, it's not we we
can't really predict, right?
Shawn: Right.
Um, yeah, the, the
the current
uh, AG Charter
is hoping that there'll be a full draft
Which, in W3C terms, is a candidate recommendation.
in two years for WCAG 3.
Um, but then the so, first of all, you know, that's
optimistic. and then it would still the
The current timeline says typically another 2 years to wreck.
So, I think this is definitely
something that we're gonna yeah, definitely something we're gonna need to figure out, is
If this if we can get
This work done in 2 years how do we handle that?
Uh, are we comfortable with
pointing to
a WCAG 2, the latest version of WCAG 2.
For now?
Um, yeah, that's a big question. I mean, the one thing is, whatever happens
This group
shouldn't try to rewrite, you know, and I think it would not be effective to try to
Fill the gaps between 2 and 3.
So, I think we need to say, look, can we, for the first
version of this work, are we comfortable pointing to two?
Um, the latest version of 2.
Uh, with the awareness of
I would just I I would see, can we
do a version soon that points to WCAG, the latest version of WCAG 2, while keeping
Charles Hall: realistically WCAG 3 = 4 to 8 years
And that is with an initial set of provisions and very few supplemental provisions
Shawn: Um, you know, a mine for
how we would do things with WCAG 3.
Wendy Reid: Okay, so I think I'm
I might disagree with Shawn ever so slightly. But I think we have the same intention.
So where WCAG 3 is at, and there was some decisions made last week around integration with ATAG
That I think we still need to iron out a little bit more, because I think there is an interest on their side to or possibly an interest on their side to, like, integrate more tightly with a tag for certain provisions, and provisions are what they're calling kind of
the full set, like, a requirement and its methods, essentially.
The draft, the WCAG 3 draft, we may actually, after we finish this exercise with ATAG, we may want to do a slightly similar exercise with the WCAG 3 draft
Where we look at what is currently there and see either if there's existing provisions that make sense like and we just can say, okay, you know, we can refer to this provision because it's, you know, it makes sense for us
Or if there are gaps in the provision where it's like, oh, we might need a requirement for insert, you know, thing like text text, not just relying on color for to describe styling
Those are things we should consider because I think that's like that would be valuable feedback for them as well, because we can say, hey
This is very firmly a content requirement we but we need it. So and we can maybe even help give some of the like framework of that in terms of implementation and stuff.
So I think we can do that, because, like, we're on kind of a similar trajectory. I do think that, like, CR in two years is I'll believe it when I see it. But
they are at a place where there are enough provisions that we definitely could be looking at them and figuring out where they fit with what a future model for us looks like.
But I do think we also want to be careful around either extent, like, I think we could extend
existing provisions, I would be reluctant for us to either reword existing ones or place different, like, criteria on existing ones, because I think that would just create conflict and confusion that would make implementation harder, and we don't want to do that.
Shawn: +1 for coordinating on WCAG 3
Miriam Fukushima: Yeah, I would agree with that because it's also important that it works as long as WCAG 2 is still in place and to also kind of take a bit of the insecurity about applying ATAG in general, because that's the problem we had so far, that it
Widely adapted
And
For that, maybe we could suggest an additional note like to the notes we already have that it's for WCAG 2 at the moment, and that the baseline is that the first guideline states that it has to
that WCAG2 is the baseline. And that authoring tools have to adhere to that, but that guidelines 2 to X like guidelines A2 to AX are
Laying out in which way certain parts of those guidelines adhere more strongly or more legs or differ in the application from normal WCAG applying to web content
If that's hear what I mean. So that you say, okay, the first guideline is kind of the baseline. We all agree everything in an authoring tool has to be accessible. But then as a second from the second guideline onwards
We say, okay, this also kind of to what Shawn said in the beginning, do we need the other guidelines if they just basically repeat that it should apply to WCAG, that we kind of state in the notes and inform the user, okay.
A2 to a X
point out differences or more strong applications or more less lenient applications of those guidelines because authoring tools are a special case.
Kind of that way
Lisa Liskovoi: Would it be an option at all to say something like that the user interface must meet WCAG 2.x or 3.x?
So to give people some flexibility, or is that
Shawn: Realistically, I
think that, like Charles said, realistically, I think that, um
WCAG3 is a long enough way off that it might
be simple. We could, but it still might be simpler to tie it to a king.
2 for now, and with the idea that we would update
With WCAG 3. But, I don't know, Charles said
Charles Hall: I was just about to say, there's not a one-to-one mapping, so that doesn't sound like a realistic
Statement
Wendy Reid: I think it's realistic. I think we can I don't think we would say maybe flat out all WCAG 3, but I think we probably could point to specific provisions
Or specific levels. But obviously with the caveat that these are subject to change and we don't you know if you want to look ahead, this is what we encourage you to do, but there will be future revision. And I think that
we can make that clear enough.
Lisa Liskovoi: Okay, so we don't have much time left. I was hoping we could spend a little bit of time digging in a little deeper into guideline 8.1. So
Sorry, 8.2. So looking at making alternative content available to authors, can we think about how
AI makes this different, because one of the things that AI can do is, of course, you can request a lot of different types of formats in terms of output.
Yeah, maybe we can spend a bit of time on that.
Abhinav Kannan: Uh, just seeking some clarity here. So, you can you
Can you repeat what you're saying with formats and outputs?
Lisa Liskovoi: Yes, of course. So looking at guideline 8.2.1 make alternative content available to authors. The intention is that authors have access to having content presented in alternative formats when they need when they need it
As Utah was giving in the example that she gave. So, can we think about how AI changes that because it is no longer a matter of just having
alternatives to formats, you can also request things so AI might change the picture quite a bit. Shivaji, go ahead.
Shivaji Kumar: Yeah, it's so I'm thinking about it in terms of
no matter what content what
what format of the content AI produces.
it should be accessible, and it should meet our guidelines.
So, you know, whether
It might produce
and a PDF, or
are in PowerPoint, or whatever.
As long as that content,
as alternative text.
is accessible and meets our guidelines, we're good.
time looking at it.
Miriam Fukushima: Yeah, I also think, that this guideline, which still covers everything, even if we don't specifically mention AI, because I'm thinking of, for example, if users' emoji or something how it's formulated
Jutta Treviranus: We also need to think about what content the author needs access to.
Miriam Fukushima: Sounds to me like it's covering everything, whereas in 8.1, we said, okay, we need an extra section, but here I think everything is covered.
Jutta Treviranus: Yeah there's another sort of dimension or facet to this, and I'm not sure I know that we'll need to think about this with the ACS,
Uh, that version, and that is what content does the author
Does the author need access to? So it's not just the accessibility of the content, but what content. So the transparency
With respect to how decisions are being made. So this is related to
to AI. and that relates to the equitable component of the AI standard, where there's a recognition that someone with a disability is more vulnerable to some of the
specific harms, so there's greater accountability and transparency required. So, um
I don't know I mean, that's likely very out of scope here with
in a way, but there are those
I'm wondering whether there is something whether we do want to have a nod towards that.
Whereby that becomes part of the accessibility.
Lisa Liskovoi: So what I'm hearing is that that probably falls on the level of the guideline because that's an additional type of information that we would make accessible. Does that sound right? So a 2.1 we have
Make alternative content available to authors, then we have ensure that editing view presentation is programmatically determinable. And then what we're saying is basically the the
process that the AI goes through to generate content is also perceivable.
Jutta Treviranus: Right, so and I mean, to some extent, WCAG is all about
whatever content you have, make it accessible.
Um, but what we're also talking about is
show us these other layers of the content, right, that we need access to these other layers of the content. The reasoning behind the decision system, the
et cetera, the, the
many other things that you might want to query about the AI and what it produces.
Miriam Fukushima: Hmm. I'm not sure at the moment if we put an 8.1.3 where we already cover
the how the user interface extends in regard to AI. If that's not enough, then already
Jutta Treviranus: Um, so I'm I'm so the what what you've
pasted into the chat, is that?
what you're suggesting.
I'm not sure whether that
goes beyond what content needs to be available.
it seems to
Suggests that it it okay, that AI content can be part of the interface. Okay, AI functionality, etc.
So depends how we we word, or what we how we defined accessible, like, is it available, is to some extent, what we want to ask as well. Is there enough information available to be able, as an author, to make
judgment regarding the equity of this content, or the trustworthiness of this content, or those sorts of things.
Miriam Fukushima: Yeah, what I see what I wrote there, like someone posted it before and I just extended it. Is like the first line and then we could like in 8.2.
8.2.1.2, do, like, an ABC or something where we like formulate that properly what it means.
Jutta Treviranus: Yeah, some something to
to indicate that the author should be able to judge the veracity, or whatever, I mean, the
what is being produced, or the reasoning behind it, so because there's a responsibility to monitor the
what is produced, and
to be accountable as an author, and you can't do that unless you and It is of even greater importance.
Um, in our sphere than others.
Ned Zimmerman: I'm just looking at the proposed guideline 1A13, and just the one thing I know we're at the time, but um
The one thing that comes to mind for me is that
carving out AI
And saying specifically that AI functionality needs to be accessible doesn't really make sense to me.
Any more than saying, like,
functionality for, let's say, editing media needs to be accessible.
If it's part of the interface, the interface needs to be accessible.
And so, I think maybe what we need to do more to
to highlight the ways in which AI interfaces need to be accessible is give specific guidance around them.
in the examples. So, for example,
a chat interface needs to be accessible.
And here's some criteria for that, or, like, a natural language interface needs to be accessible, here's some techniques for that.
Um, because I think
you know, AI interfaces can be implemented using web technology, they can be implemented using desktop applications, they can be implemented in different ways.
And those implementations are also used for non-AI interfaces, and so
I guess I just have some
questions about what what that does specifically, but
Miriam Fukushima: Yeah, I think maybe to bring Jutta and Ned together is like, I find it important to point that out at that point because with AI we have the merging of content output and interface into one feature
And that what the AI output well, I see the danger that if the thought process is seen as AI output and not the interface itself, that this is not accessible to users that need the
need to have access as well to make a confirmed decision about what the AI is doing, especially not only the thought process, but also like
warnings about how the AI operates, or what it limits are, or how to not work with the AI, like, all those things around the AI, which are technically, technically speaking, output or content
What are necessary to operate the AI and are the user interface and have nothing to do with the actual editing of the content or the content itself.
But also maybe initially not there because they are generated while using. That's kind of my idea behind it.
Jutta Treviranus: Yeah, I agree with Miriam.
Lisa Liskovoi: Yeah.
Agreed. Yeah. Okay, we're a couple minutes over time. Thanks, everybody, so much for the discussion today. And we'll see you in a couple of weeks.