Meeting Minutes
Wendy Reid (she/her): Awesome. All
right.
let's move on to the
main topic for today, which is continuing our
review.
of the guidelines in ATAG 2.
So, we
started Principal A3
last time,
Principal A3 is pretty hefty.
in comparison to A1 and A2.
So, I thought we probably
need a little bit more time.
just to wrap up A3 before we continue ahead.
where we
left off last time was we had ended up kind of in a discussion of
history slash,
progress why am I forgetting the term?
Ned Zimmerman: Revision? Yeah.
Wendy Reid (she/her): version control,
thank you, Miriam!
and where does that fit?
A3 contains, you know,
the
requirements around, like, text search, preference settings,
preview interfaces,
so
is there anything in here that we didn't cover last week that we want to call
out?
Ned Zimmerman: There's a couple things
that I've been looking at in this,
between the last meetings that I was at.
A.3.4.1
and A.3.4.2, the Navigate by structure and navigate by programmatic relationships, I think there is
maybe some potential there
for,
AI tools to support that.
I think about things
where, for example, say you want to generate a table of contents for all the headings in a document,
and be able to
jump between them from, like, a little list of table of contents links at the
beginning.
that's the kind of thing that some authoring tools would
support.
but would require built-in support to do that.
Whereas, in theory,
properly integrated AI tool could be instructed to
create that table of contents, or
create those links to
jump between sections of the document, or the editing view,
programmatically.
and then I think the other
piece is that there's some potential
for.
text search to be enhanced by the presence of an AI tool, but again, there's
I
think there's, for both of these, there's really clear
parameters that would need to
be in place to make that work properly,
And accessibly, but there is some potential there, I
think.
areas of opportunity, maybe.
Miriam Fukushima: Yeah, I think what's
important here is that our better definition of content that we're going to make is really
important for this point, because
we already realized that we will have two types of
contents, the content that is actually being authored,
And the content that might be part of the
editing interface and part of, maybe generated by AI.
and that both
I'm meant
here, because I need to if
And the AI gives me instructions, or gives me extra resources. This
also needs to be marked up, but also the content that I'm actually authoring.
and either
we need to make a distinction here that
We only mean the content that is being authored, and then
we need to the content that is generated as resource is covered by the previous points of the
user interface, or we need to,
mention both types of content here, referring to our
new
definition of content.
Wayne D: Isn't Part A just referencing
the editing interface in Part B as
editing the
Content interface.
Ned Zimmerman: I was
just gonna say, I think the nuance there is that part of the editing interface is
the preview,
or in some cases, the WYSIWYG
content editing area, which does include the content as well,
and so the accessibility of that is
falls under Part A, whereas the accessibility of the final
content
I I maybe the final content or the output is what would be
considered under B.
Charles Hall: There's
a phrase in 341
that I just re-read, like, 4 times and still doesn't make sense to me,
and it says,
select move the selection focus.
And I don't understand what selection
focus means, since in the context of the web, those are two different event types.
and
It
also occurs to me, upon reading that, that in the authoring environment,
There are previews of
components in isolation, and there are previews of components in a rendered
page.
And
sometimes,
either or both of those rendered previews
would not be focusable
if certain
apps,
attributes
were omitted.
So, like, part of the authoring environment provides the
content
But part of the deployment process provides the attribute values that then make that
control focusable.
So, it's oddly worded, and
focus won't always be
possible.
Miriam Fukushima: Yeah, I think with focus,
it's meant that you have
to be able to author it, so if, for example, if you have a
paragraph with just plain text, obviously in that context,
the plain text won't ever be
focusable in the way that you have you can move your keyboard focus to it naturally.
But as an
authoring tool, you need to be able to focus it to
insert blanks, or
type or
change the word, or whatever.
that is one thing.
And what I wanted to
clarify to
what I meant before, is that if we start to
If you revise this A tag and change our definition
of content and start to
use the word content in multiple places, then
we have to change
the
places.
in ATEC, where we use content and need to specify which content we
mean.
and here, it's meant it's the authored
content, so the content that will
be authored.
and either we give a note to the content that is also generated in the user
interface as
addition, or we say, specifically, we don't mean that in this place, we mean
the authored content only.
so just to make the
the word content more clear,
because
One goal we also wanted to achieve is that ATEC is more easily applicable.
So, we
should make sure that the
use of the word content is very clear in every one of these
cases.
Wendy Reid (she/her): Yeah, one of the I
think the interesting thing we have to deal with we discussed it previously a bit Wayne,
just for your own background,
is with the addition of generative AI, the authoring interface now
has this added
layer of content
that is related to authoring, but is not the authored
content.
And but is essential to the authoring process, like, the chat interface, or the canvas
that you work in.
and it needs to be just as accessible.
and interactive,
but
It's
not part of the final prop. It's very
We almost have to have a good
concept of, like, the authored content,
And content related to authoring, but is not part of the
final product.
It still counts as content.
Ned Zimmerman: I just
wanted to highlight a couple comments in the chat. Mike had mentioned I think related to the
version control.
a a 411 content change is reversible.
which is sort of I think you
sort of said, Mike, that
It sort of describes version control after fashion, and then
the other comment Mike made was about
whether we I guess, are you asking if we want to keep the
reference to UUAG, Mike? Is that kind of what you were thinking there?
Mike Gifford (CivicActions): I just
don't know that anyone because the browsers and other user agents don't care about what
the WC3 says, at least that's what it seems why are we pointing to a
I guess that
of guidance that is our good best practices, but have not been adopted by the industry, and
that
that we're not like, the industry doesn't refer to them. So, why are we? Other
than it's another good W3C practice that everyone should be following, but isn't. So, I
just just wonder if it's relevant, or if it just, like, oh, you're out of date because
you're following this 2015 guideline that nobody pays attention to.
Ned Zimmerman: Yeah. That's
that's fair.
Definitely worth considering.
so we were talking, I think, about
the A341 and 342.
any other points on those before we move on to A351, or A35,
rather?
Okay, not hearing anything there I'll say let's talk about
A35, which
is search, tech search of the content. As I said, I think there's potentially
some
possibilities for generative AI tools to help with that.
But I don't know if
there's anything here in particular that we want to call out that needs
further attention.
Okay, should we move on to manage preference settings?
So
I think the
8361
is
around display settings for editing views, which is essentially, as I understand it, it's
changing the way the preview appears without modifying the content that's being previewed or
edited.
I think there have been conversations in previous meetings about
user
preferences and sort of user customization, and the possibilities for that. I think this kind
of
This and the other two, kind of,
follow fall into that category.
Are there any
points around this
that folks want to bring up.
Wayne D: I just turned it off instead of
turning it on. Okay,
You know, this is based on what Greg 2.0.
And there's a lot
of
readability stuff that has come in in 2.1 and 2.2.
I was on the low vision task force when
they wrote the Low Vision section.
And I think that we really need to broaden this.
to be a
point of view for
print disabilities.
people would print, and I think it comes out in this
one.
You know, we're not talking about user preferences here. We're talking about
setting the screen so that we can see it. For example, I can't
really, you know, when you
referred to the chat, I can barely see the chat.
And if I enlarge it, then I can have half a
message on it one time.
And so the layout of the screen and the color of the screen and the
spacing of the text is
you know, I'm not a
not an option. I mean, I proved that,
doing an enlargement with that brewflow was,
and accessibility issue, not a user
interface issue.
You should be very careful when talking about user interface and visual user
interface, because
A lot of people adjust their user interface so they can actually use
it.
Ned Zimmerman: Yeah, definitely.
Wayne D: And for example, people from many,
many people with low vision
As opposed to people who are blind, don't
Don't use
keyboard access. They don't give a damn. They want to use
the mouse, you know? And, I think they're
winning.
So, I think that's an important thing, you know, about necessary visual user
interface, and
And kind of fun stuff.
I think this was written a little before, but
there were
They were pretty aware of those needs when they wrote this.
Ned Zimmerman: Yeah, that's a good
point those are good points.
And I think I think
part of that probably fits
into
The A3.6.3 respecting changes in platform display and control settings, so I could
imagine things like high contrast modes screen zoom at the operating system level,
or
other features that
potentially need to be expli I guess, high contrast mode is maybe the one
that would need to be explicitly supported.
But making sure.
Wayne D: And it's far more than that.
High contrast notes supports people with blurry
vision, people with central retina damage don't need that at all. In fact, they need another
one in the face. And people with tight central,
acuity, you know, with
peripheral field must need a whole other interface.
you
know, one of the things that's
Low vision isn't
Isn't the spectr
it's a tree. And, you know, what you need is
the interface for the disability. And then, of course, if you have dyslexia on top of that, you have
to
have an interface for that. A lot of times, it's, like,
line separated by 10 line
spaces. I think we want to think in terms
of print disabilities when we think about this, not one or the other.
That's all. So these sections, I think, are important, and probably do need to be strengthened.
I'll read them carefully.
Miriam Fukushima: Yeah, so that would be my
question to Wayne. If you think that
something like, if we insert a must in this,
from you in this string of words, like, for example, the authoring tool must.
respect. If
that's already enough, or if, like, if we,
link it to newer WCAG specifications, if
that's enough.
Like, how do you think,
We should change this, then, going on forward,
just as a question.
And also, you don't have to have the answer right now, of course,
obviously, but yeah.
Wayne D: yes, I think it should be a
must, and the reason it wasn't a must in the time, because ATAC and
was being finished
up, kind of, at the time that the Low Vision Task Force was
identifying what the level
AA
items were. And so
And they couldn't get to a complete resolution for the,
Pulmonary disabilities, but they could get to a
real conclusion with low vision, and and
so I would say must, and
I'll compare.
the low basin criteria with this, and see what
updates need to be done.
Ned Zimmerman: Awesome, thank you, Wayne,
that's great.
I also wanted to just mention Mike put in the chat that he believes
that the EN301549 standard may be ahead of WCAG on user preferences, so that's definitely worth
looking at as well.
I know that's something we've been looking at a little bit,
too.
Anything else on the 3.6 section on managed preference settings?
before we move on to
a 3-7.
Charles Hall: response to Wayne's
comment,
3.6.1 is basically saying,
If the tool provides
the author control of
settings,
then the result of those settings differ from the result of the published
content.
what what Wayne said exposed a huge gap, which is
It doesn't mention
any
specific
type of setting or property for that type of setting.
like WCAG gives a threshold of
what text should be able to be enlarged to, that kind of thing.
so it's it feels
like
There's a significant gap
with 3.6.1.
that the type of setting and the properties
are not even mentioned.
Ned Zimmerman: That's a good point.
Wayne D: At the time, they wanted to,
get as much of that in as they could, and they knew that
3.1 was coming.
And so they
tried to make the language as close to that as possible, but they
You know, they didn't
have they didn't have 2.1 at the time, so
they got it as close as they could. So,
I'll work on seeing if we can make that make that match.
Ned Zimmerman: Okay shall we move on
to
A37, so this is around ensuring that previews are at least as accessible as in-market user
agents.
So I think this is something I know, Mike, you had talked about the reference to
UAAG Level A.
Yeah, any additional thoughts on this, or from you, or from anyone
else?
Charles, yes, I see you're in the queue.
Charles Hall: one thought here on
3.7
is it uses the word
display.
And render.
But that omits
the other forms of
presenting content.
So, I wonder if
we could align closer to WCAG,
and say,
present.
Versus display or render.
Because the presentation also includes the audible
presentation and the
the tactile presentation.
Ned Zimmerman: Yep.
Yeah, less because
it is it is sort of implicitly visual here.
Whereas what we're really looking at
is the
accessibility APIs working the way that they should work for any kind of assistive
technology?
Yeah, I like that. That's a really good idea, I think.
oh, Mike has a
point in the chat which says, isn't WCAG 3 going towards Vue as a general term? I can't
speak to that, I'm not sure if anyone else knows about that.
Charles Hall: But it is, but in the sense
of the scope of
what a provision covers and what conformance covers, sort of the size of
the container versus
how content is presented in that container.
Ned Zimmerman: Right,
okay.
Gotcha.
Yeah, I think that's a very meaningful change. I think that would be
good.
Anything else around the preview capabilities here that others would like to
mention?
Okay,
Should we move on to A4?
So this is around editing views, being
understandable. This is the last part of
Section A.
so for
Guideline A41 the
interface helps authors avoid incorrect mistakes.
so I think A411 Mike, you had talked about
that first point around content changes reversible being sort of similar to some of the version
control things that were being discussed at the last
call,
Is there anything else that
wasn't
finished in that discussion that others would like to bring up from from to follow
up on that point, or do you want to add anything more to that, Mike?
Mike Gifford (CivicActions): No, I mean,
I'm just looking at just recognizing things that were different, or since since
I mean,
anytime you look at a document you haven't looked at for a while, it's like, oh yeah,
there's that, and, you know and there are
things that are better
certainly better supported now than they were. I mean, the auto form
fill-in is much better now than it was, so
you know, trying to you know, that's not as
rare a thing.
Charles Hall: it it occurs to me that
this
assumes a specific
session type and flow of activities from the author. Which is
immediate
as I'm as I'm actively adding and editing content, I should be able
to reverse a change that I just made.
What it doesn't extend to
then is,
a space
that falls in between that and version control, which is
an approver workflow where the content
change that has been committed
has also been approved by someone else.
And then that
change
still has to be reversible.
So it's like the
it it seems
to
automatically assume
while editing versus edited content.
Ned Zimmerman: Yeah. This also builds on
something that I think I mentioned a couple months ago that has been in my head since I started
working with this project.
Which is around the
The assumptions of a sort of
I'd say,
like, quasi, like, linear, piece-by-piece editing process that
An author undertakes versus a
situation where a generative AI tool may, like, redraft an entire
document or block of content at
once.
And then it's less like, oh, I changed this sentence, and then I changed this
sentence, and then I changed this sentence. There's, like, a linear set of changes that have
been made, as opposed to a full rewrite, or
transformation that's undertaken when you
prompt an AI tool to say, like, rewrite this in a less formal tone, or something like that.
I
think it becomes harder to track those changes when they're
I mean, it's like, anyone
who's ever seen a diff where every line changes in code,
And then you're trying to
figure out what the sequence and nature of the changes were, I think that becomes more of the
challenge when you're working with generative AI tools that can
transform the entire
document, or or
piece of content being edited in one fell swoop.
so that poses
additional challenges, which I think we need to engage with here.
I'm gonna go to Miriam
now, because I know you'd had your hand up.
Nope, good, okay.
Mike Gifford (CivicActions): I can speak at
the spell check one, just that, you
know, spell check was, I just posted in the chat. I mean, yes, spell check, but also grammar
check, and but it's with AI, there's so many more tools, like
tone, plain language,
content, style guides, like, all that stuff is becoming
easier to implement, and not
Not as
much of a burden, but I the other thing is that was not here when this was first built was the
idea of the
progressive web apps and all of these
these offline modes, and how do you
manage
An editing interface where you have more than where you're not dealing with a
live
a live server.
Ned Zimmerman: And reflecting the state
changes between an offline mode and then the synchronization when you reconnect, and yeah,
that's a good one, too.
I think that's definitely worth worth including
here.
I actually think I remember seeing recently some sort of grammar
check tool that
was advertising itself as local advertising itself as local first, and that ran
Using service
workers in the browser or something like that, and wasn't interacting with the server, it
also
So things like that come into play here in a way that they certainly didn't when ATAG
2 was written.
So that's a really good point, Mike.
so we've talked quite a bit
about the content changes. In terms of setting change confirmation,
Yeah, Marianne, go
ahead.
Mary Ann (MJ) Jawili: Hey just to kind
of
go to your point, Ned, that you were talking about with AI possibly making lots of
changes in one fell swoop. Sorry, I don't know where this fits in the
any tag, but,
I think that is important and
we shouldn't just be able to, like,
undo
Because undo might undo everything.
the user might want to just undo certain parts
of it.
so
I think that is definitely something to consider. It's a little bit
different from what
the A tag that we have today,
did not have in mind, I
guess.
Ned Zimmerman: Yeah. Definitely, and I
wonder, too, like,
I don't use AI coding assistance, really, to speak of, but
I've seen some writing about
techniques that people use to say specifically,
like,
don't make a bunch of changes at once when they're prompting the tool. They
say,
Ned Zimmerman: change this function, then
change this function, then change this function, and stop for confirmation between each
change.
And I could almost see something like a guideline
Similar to that, that says
that
AI, generative AI authoring tools should
make discrete changes one at a time to allow
the author to
And this falls into some of the earlier things here, too, where
we've
been talking about, like, the time to process changes that are being made, and, like,
the
cognitive load of a bunch of things happening at once.
it's kind of a way a mechanism for
feedback and assessing what's happening in a structured way, as opposed to having a
whole
big swath of changes coming through at once, so there could be something there
where
that becomes a piece of the guidance. I'm not sure if anyone has ideas or thoughts
about that, or
thoughts about how to articulate that, but
That seems like a beneficial way
of addressing this, maybe.
Wayne D: I continually have to remind my
AI
but it has to talk back to me in a way that I can listen to.
And I even have a
little,
blurb that I give it on every time I started chat, that it reads it, and
it's
That, you know, make this,
read out loud friendly. And I have to do it on the other
end when I'm finally preparing a document, and sometimes when you'll iterate a document
with AI, you'll give it an accessible document, and it'll give you back an inaccessible
document.
And you have to say, no, keep the accessibility.
functional, and you have to keep
reminding it.
Ned Zimmerman: I was just gonna say that
definitely falls into
stuff that we'll get into in Guideline B12, ensuring that
accessibility information is preserved.
So, in the context of working with AI-based authoring
tools, making sure that
When they're making changes to the content, they're not
stripping out accessibility information as part of that process.
but,
Setting change
confirmation, I don't know if there's anything we want to talk about with that. Sorry,
back to A412.
Oh, Charles, I just want to pick up a couple things Charles put in IRC. The
definition of authoring action says any action and could perhaps extend to any sequence of actions.
I like that, that's a good way to think about it.
Unlimited, undue, or unique action undo,
so
those are good points, Charles, thanks for that.
Unless there's anything
else for the 4-1, maybe let's move on to A4-2.
Which is document the user interface,
including all accessibility features.
So the first one is describing accessibility features,
and the second one, A422, is documenting all features.
There's different ways to meet
these,
For ways of meeting each of these.
I think one thing that I noticed in
some
review that I was doing,
There was a paper where a number of generative AI-based
website building tools were evaluated, and one thing that was highlighted with many of them is that
they don't mention accessibility at all in their documentation in any capacity.
they may
have some accessibility capabilities, but they're not mentioned, and they're not
described and
How to actually use them is not described anywhere.
so
that's
As relevant as it has ever been, possibly more so in some ways Miriam, go
ahead.
Miriam Fukushima: Yeah I think that
the note
underneath D should maybe be an E instead of just a note.
that it's
required to that the documentation is also accessible.
especially
Wayne D: Yes.
Miriam Fukushima: Yeah.
Ned Zimmerman: Yeah, that's a really great point. Charles, was that what you were going to say as well? I saw that you're
Charles Hall: no so
there's
When we have wording like this that says one of the at least one of the
following is true,
the challenge is that sometimes more than one can be true.
Which is
presumably a benefit, however, when that occurs,
they may be in conflict.
Ned Zimmerman: Yes.
Charles Hall: So if the description and the documentation and the description in the interface differ, now you have a new problem.
Ned Zimmerman: Yep.
Yep, definitely. Or
when the documentation falls out of sync with the interface, when the interface is updated
we've all seen that before. Yeah, that's a really good point.
Yeah, no, I think
that's I think that's an excellent point. I think
maybe some
some ways to capture
that in these individual,
ways of meeting the criteria would be would be helpful.
so
that's duly noted. Miriam, go ahead.
Miriam Fukushima: Yeah, so maybe that
should be a note that documentation has to be updated.
And kept in sync with the actual
interface.
Ned Zimmerman: Yep. Yeah, that's a
good point. That's a good way of thinking about it.
Okay.
anything else for
documentation?
Mary Ann (MJ) Jawili: hey, this is MJ,
Ned Zimmerman: Yeah.
Mary Ann (MJ) Jawili: I don't I
don't I'm having a hard time understanding I get part A
4.2.1. That's, like,
meeting part A, but
what is 4.2.2 about? I don't quite get it, it seems the
same, I guess. Yeah.
Ned Zimmerman: Yeah, no, I get that. I
think I think the
The difference here is that
It looks to me like, because A.4.2.1 is a level
A, so it's like a very baseline requirement, is that
In order for an authoring tool to be
accessible, all the accessibility features have to be rigorously documented.
Mary Ann (MJ) Jawili: Okay. Yeah.
Ned Zimmerman: And then to make it even
more accessible,
that expands to make sure that all features are documented.
Does that make
sense? So the level AA is
still a pretty
important requirement, but it's just like a
Yeah. Next year level.
Mary Ann (MJ) Jawili: Yeah.
Ned Zimmerman: Okay. do we want to
talk is there anything else in general around
Around principle A
around, rather,
the
Authoring interface section
that we want to talk about in general that hasn't been
covered in these before we start thinking about
Yes, MJ, go ahead. And MJ and then
Miriam.
Mary Ann (MJ) Jawili: Yeah, I was just,
I don't know if we've talked about this, apologies if we have.
But,
maybe there
could be something that covers
like, co-collabor like, collaboration on a
in an
authoring tool, like
Ned Zimmerman: Right, collaborative authoring.
Mary Ann (MJ) Jawili: You can when you
have multiple people editing, yeah.
Exactly.
Ned Zimmerman: Mm-hmm. Yeah, that's a really good point because that's certainly more,
Ned Zimmerman: more,
common than it
was when ATAG2 was published.
I remember
Wayne D: Actually not, but the truth is that it just needs to be there.
Ned Zimmerman: Yeah, yeah. Yeah, I mean, I'm speaking more to
Wayne D: Yeah.
It probably should have
been there back then, you know?
Ned Zimmerman: Yeah, yeah. I'm
speaking more to the, like, real-time collaboration interfaces, which I know, like,
having worked
in WordPress back in the day, there was always the post would be locked if someone else was editing
it, and then once they finished, you could edit it, and now I think they have some real-time
editing, where multiple people can work at the same time.
that's more common than it is
than it used to be, but definitely, definitely should be there. Miriam, I see your comment in
the chat, a side note, which was this, that
I'll just read this out. In regard to what
Wayne brought up on the topic of user preferences,
Maybe the introductory note 3 developer
control should be made clear that even under Activated User Preferences,
Developers still have to
make sure that focus is visible, just as an example.
So that user preferences can't make it
less accessible, I guess. Is that kind of what you're getting at, Miriam?
Miriam Fukushima: Yeah, exactly.
That's what I wanted to say, that it's not a, like, free-for-all, just because
someone has user preferences activated, that all is out of the window, kind of,
Just to make
it clear, I mean, it could be implied in the Node 3, but I think it's important to make it
clear.
Ned Zimmerman: Yeah.
Mike Gifford (CivicActions): But if you if
your user preferences are for black on yellow,
That might be really good for you, but horrible
for any other person who's trying to view the page.
So, I mean, I think that user
preferences are innately personal, so
we can't necessarily,
determine whether or not
it is
Yeah, I was wondering, like, a little piece
Miriam Fukushima: now,
No, I
don't mean that you have to cover all user preferences, and like, let alone the
combinations possible is, like, more than stars in the universe, but
that, for example, if I
make a style sheet for force colors enabled,
that I have to find alternatives
for
if I use, usually I don't know, an icon to mark my focus,
And,
in
user preferences, I obviously deactivate that, because I can't make sure of the colors, I
can't make sure what would be the background for the icon, so I better deactivate it, but then
I have to make an alternative that I use, like, a border or something.
and that I
can't say, oh, it's user preferences. I deactivated it, and
POCUS is just not visible
then so that still needs to go more thought into
just respecting user preferences
is
not only just, okay, if it's activated, I just let it be, but I actively have to,
make some alternative for certain things because of user preferences that have nothing
to do with
The actual colors, or the actual preferences, but there are still steps that I can do
to make
the accessibility,
or to guarantee accessibility,
that otherwise, if I
just say, oh, I expect user preferences, and I'm done,
it's not enough.
But that
there are still things that need to be done, and that should be done,
And that I can't use
the excuse with, oh, it's user preferences, I just
respect them, I activate my stylesheet,
but
that I actively need to think about, and this also needs like, if I develop a product,
this needs extra planning, extra conceptualizations, time, I need to plan in.
to make my
product accessible,
that needs to be covered by expenses. And if I just
say, okay, I
have a style sheet that just
forwards the user agent colors is not enough. I need to think about
certain alternatives for for things that
I have on my interface in my authoring
tool.
And focus is one that comes across in my work most.
predominantly, that's why I
said it, but,
Yeah.
Wayne D: Yeah.
Mike Gifford (CivicActions): through some
possible wording language in the I don't know what's a good one, but just some ideas
about ways to
phrase that.
Ned Zimmerman: Yeah, build a robust product.
Wayne D: You know, there are so
many tools that if
you try and change the interface
turn off a whole bunch of your
You know, so
you know,
I've had in fact, I juggled that all the time. I go to this
tool that I'm using to
produce one kind of document, and I
change the interface, and then I know that I don't have
these things available to me anymore, but I, you know
Some of us have to change the interface
back, so I'll have a tool available for me. I mean, this is a
You know, they
they're
Authoring tool developers make these assumptions that, oh, you you
you put the
interface this way, you don't need these things, you know. And it hasn't gotten
better.
Charles Hall: some another gap in the
A section.
ties two of the conversations that we've just had together.
which is
environments that allow multiple authors at the same time.
with the
reminder from Miriam that
if we update the definition of content, we have to update the references to content in other
criteria.
so in that multiple author environment,
there is content that is
intended to be
conversation between authors.
commenting tools. And there's no reference
to that type of content that exists only for authors in the
authoring environment.
Ned Zimmerman: Mm-hmm, that's a really
good point.
And I think there's gonna be some commonality there between
guidelines for
how to make
inter-author communication,
That's part of an authoring tool accessible, and
to How to Make Chat Infaces with a generative AI tool that's part of an authoring environment
accessible. There'll be some overlap there.
so definitely good to incorporate that into
the work as well.
MJ, I'll go to you.
Mary Ann (MJ) Jawili: this may be
related to previous conversations around user preferences, but
I'm wondering if
there's
I'm thinking of how, like, a lot of authoring tools, like if you're
building a webpage,
they offer both light mode and dark mode automatically.
Just out of
the box, and
that's not a requirement, but it's
having these options
avail- just easily available does make it
kind of I guess, easier to
It's
kind of an accessibility feature in a way, I guess, and
I guess along those lines, I'm
wondering if authoring tools could
just offer,
other
other UI features that, you
know, switches for
for the for the reader just kind of out of the box.
and maybe we
could kind of make that, like, a requirement. Like, it's not a requirement right now, for
example, to offer a light node and a dark mode.
But, anyway.
Ned Zimmerman: Yeah, I think I think some
of that does kind of fall into the or could fit into the
platform accessibility services,
section, like, A122, like, I know that
different operating systems have
operating system
level
dark mode, light mode, high contrast mode.
And the the part a part of
the
you know conform you know,
Sorry, I'm struggling to find the word
here.
part of the
compatibility with those could be make sure that the authoring tool
supports
those kinds of changes if the user has
made them at their operating system or browser
level.
this ties into some of what Wayne was talking about with Zoom as well,
but
but I think
certainly that's something that could be considered here.
Yeah, other other general thoughts? I know we're getting close to the end of our time,
so I think we'll probably start this Section B next time.
Wayne D: I think one thing is maybe
user interface preferences?
should be changed to user interface requirements.
Ned Zimmerman: Right. So what the user needs to be able to use the interface?
Wayne D: what the user needs to be able to
use the interface exactly. You know, at the time
For
example, we're wrapping was considered a usability.
issues, not a not an accessibility
issue. So, I mean, that's the kind
of thing that
So they used preference at the time, but I think they wanted to use
requirements.
Ned Zimmerman: Yeah.
No, that's a
meaningful language change.
to think about, for sure.
I don't see anything else in
IRC,
any other hands?
Mike Gifford (CivicActions): I just made a
comment about the light and dark mode being an
accessibility feature, and highlighting
CSS media queries, including things like reduced
animation. Like, animation is a
Ned Zimmerman: We're just motion, yeah. Yep.
Mike Gifford (CivicActions): I mean,
animation is a really important tool for being able to help users identify the focus.
of the
page, but can also be a really
tool for making people sick. So, making sure that people have the
right
the ability to override it, but also the ability to go off and use that in ways that
make the user interface easier to understand
For greater comprehension.
Ned Zimmerman: Yep.
Yeah, I'm just
looking at all of the,
prefers color scheme, prefers contrast, prefers reduced motion,
prefers reduced transparency.
there's also the prefers reduced data, which is never
really implemented anywhere, but is a nice I mean,
That ties into some of the offline-online
editing affordances that was brought up earlier, is that
you know, an authoring tool should
degrade gracefully if the connection is unreliable. I mean
I don't know if that will fit in
here, but I I personally love it when I don't
of all my content disappear if my Wi-Fi
drops out, but
Charles in IRC notes that another useful consideration is to not
override the expected cursor, which I think is a really interesting point.
I like that.
Yeah.
Okay, well, we're just about at time. thanks for the discussion today,
everyone.
and we will reconvene again in a couple weeks, and I expect we'll be
starting
to look at the section
B, which is support the production of accessible content.
So if folks wanna wanna start looking at B1 and B2 to prepare for that, that'd be
great.
But thanks again for a thoughtful discussion, and we'll see you soon.