I love a warm welcome in this excellent.
And also, I have stickers at the end, especially for people who
clap at, if I make jokes or anything about our stickers, yes,
to get ready to read.
So my target, sorry, my name is Mike Gifford.
I'm an open standards and practices lead at civic actions
where a US-based company, I'm a Canadian
live in Ottawa, Canada.
We do a lot of work with the government.
I'm also a WC3 invited expert.
And I work with folks like HITTY on all kinds of stuff
at the WC3 and really have an opportunity
to learn from experts.
And I came to this to accessibility
from the Drupal community.
And Drupal is a large content management system.
And I've been spearheading the accessibility
initiatives in Drupal for, I don't know, since 2009.
So I don't want to do the math.
But I've learned a lot through the process.
And we were also for ATHG, the offering to accessibility
guidelines.
We were one of the two test cases that were acquired
in order to get that standard into place.
It's been a really interesting opportunity
to learn about how to go off into incorporate
accessibility into offering tools.
And so I wanted to walk through some of those ideas
and also look ahead at where we're going.
There's a lot of changes right now for authors
as for our VWNLs.
So right now, we're doing, we're doing some
as a little bit insane.
We're not really expecting for some reason
authors to become accessibility experts.
And so there's a cycle of failure.
You'll look at all of the, I am also authorizing
that one of the authors of the Web Almanac this year,
the accessibility chapter.
And as part of the Web Almanac, we're
trying to evaluate how much of the Web
have we being, how does it look, how accessible
has it compared to last year?
And despite things like the European Accessibility Act
coming into effect this past year,
we haven't seen a great improvement
over the accessibility in Europe or many other places.
Strangely the one place where we have
seen improvements in accessibility, the dot AI domain
is now the third most accessible top level
domain in the world in the surveys that we've done.
So there might be something there.
And we need to train authors because they change over time
or they have other subject matter experts in other areas.
They're not trained or have the time
to be accessibility experts.
And we should expect them to.
We need to be starting to use these tools as filters
to help authors create better content.
We need to be more strategic about how we do that
so that we're, and shift the focus from authors
to authors, because right now we're all of the energy,
all of the focus, all of the money in the accessibility
industry.
And there is a lot of money that isn't
is going into the accessibility industry.
It goes into auditing.
And that's not a good space to fix the problems.
If you wanted to fix the problems,
we need to be looking upstream, looking at fixes
to open source tools, like Drupal and others,
and not focusing on auditing.
So it's not really a missing standard ATG is out there.
It's just not applied.
So many people who have heard about the web content
accessibility guidelines, they may have heard about
the evolution of those guidelines
and how we're now moving towards the WKG 3.0, which is great.
And there's lots of interesting stuff that's happening there.
There might be a WKG 2.4, who knows.
Certainly we have a, or sorry, 2.3.
There's certainly a 2.2 right now that will probably
be coming into law in the, in the Ian 3154
and our 9th standard in the next year, I hope.
But so often organizations overlook authors
and look over the people who use their interface.
And in Drupal, we've been incorporating
and thinking about authors since Drupal 7,
which is a little while ago, because it's reached the end of life.
But most people don't think about the 25% of the population
that has a disability.
And we're not, you know, that includes authors.
It's not just the general public.
If there's government employees or university employees
or using these interfaces to provide content,
that includes that 25% of the population.
Part B of A tag is often completely forgotten.
Like sometimes people will think about part A
trying to make the back end accessible.
But they won't often think about part B, which is,
how do we try and support those authors?
How do we build in systems?
So this easier for authors to do the right thing.
And not to suddenly assume that those authors
are going to be accessibility experts.
And so there's things that we've done,
like in Drupal 7 or sorry, Drupal 8,
we work to, when we tried to address A tag,
we did things to make sure that all text was required
on images.
And we were going to, one of the first CMSs to do that.
And it was a really excellent opportunity
to try and take this material and try and say,
how do we apply it in the context of our content management
system?
Now, A tag 2 is an decade old.
It hasn't been applied all that often
to a lot of content management systems
because it hasn't been required.
It's not part of contracting in general.
It's not part of legislation in general.
And now we have a rush towards adoptions of LLMs
and that's adding the additional pressure
to making things more accessible.
So how do we try and end this process?
Get move from from having guardrails,
like error messages that pop up that say,
oh, this must be like, you can add error messages
and validation errors to sort of force authors
to do things, but it would be a lot better
if we could provide better guidance, provide better tools
in line so that we're thinking about accessibility
like a spell check.
We would all, if we took away spell check right now,
all of us would be worse writers
because we expect to have the spell check there
and grammar check.
Like these are things that are built in
that support our communication.
We don't have that yet for accessibility.
Even though there's tools built in
to do accessibility in a lot of places,
nobody includes them by defaults.
And we need to start changing that.
Julia actually is one of the few CMSs
that includes Sally by default.
Sally will come up later.
But there's a, it's trying to,
to think about how do we support
the authors and the creation of content
is a real challenge.
But AI also gives us the ability
to provide more customized information.
So, do we want to provide information
that's for different audiences?
Do we want to provide a plain text version
and easy language version?
Do you want to provide it in different languages
for different roles?
Like we can do that now.
And a lot of that is actually getting built
into the browser.
There's AI in the browser,
which will provide some interesting opportunities
to go off into to customize and personalize information.
It will also introduce a great many problems.
So, by no means as AI is a panacea
that will solve all of our problems
that is both going to give us more problems
and more solutions at a faster rate
than we've ever seen before.
So, about four years ago,
the Funka and Sweden went off
and let an international study in preparation
for the European accessibility act
to try and get the content management systems
that were popular in Europe
to start thinking about improving their offering and interface.
And there's a bunch of organizations
that came and were a part of that.
And he didn't want to take the A-take process
and just reuse it.
They wanted to be able to look at finding out
what are the practical tools,
four CM authors that we beneficial for them.
And there's a bunch of stuff that came out of that.
And there were several CMS authors
and editor editing projects were involved.
Like, we had Sloan and Jumla and tiny MCE
and a few others that were gathering
on a regular basis for over a year
to try and think about what we could do
and create a report to provide to the European Union
or to the European Commission.
And we got some interesting ideas.
And I think we actually have the only user research
done for authors on creating better content.
I don't know that anyone else has done user research
on accessibility for authors, which is a real shame,
because this is a real sticking point for problems.
And we don't know why authors are creating terrible,
terribly inaccessible websites.
We're not going to fix the problem.
So we need to have more studies like this.
But that was now over four years ago.
And AI has changed things.
How do we try and think about what is changed
and how we can make this better?
So from the Funker report, there's a few things
that are there that jumped out.
One is the challenges with changing languages.
And that's still a problem.
In fact, Sally, Adam, I've got Adam's last name
as it starts with the C. Sally is a S11Y.
As an open source editing tool, that was the built out
of the University of Toronto, the Metropolitan University
of Toronto.
And he's in working with John from Princeton
looking at creating tools to help identify
when language or parts is being misused.
Because it's all this devicade criteria,
success criteria language is easy to explain.
But there aren't that many language tools out there
that make it easy for people to understand the problems.
But table creators, all text generation, form editors,
they created a list of things that they wanted
to have built into content management systems
and some roadmaps and templates to do that.
And I have an archive of that if people are interested
in seeing the results of that workshop.
So looking ahead, we need to have, I think
that we are going to have to try and find better ways
to use AI to create to help authors.
And it is going to have to go and to be a privacy first approach.
We're going to need to look within the boundaries
of the content management systems that we're using
to see one of the limitations of this.
We're going to have to find ways to improve the quality
and use AI to not just produce more slope.
Because AI can produce content so fast.
But can it actually help authors improve the content
and improve the quality of the content?
Whether it's thinking about different roles,
it might be reading it, whether it's just double checking it
to make sure that you're doing more than what
primarily can do out of the box.
Like there's AI can provide additional information.
And yeah, we want to make sure that when you're using AI
and you're doing your own doc,
you're doing work that information isn't getting leaked
to third party parties, because that can be problematic.
I do think that it's useful to try and think
about having LLMs that where there's a choice of models.
So you're not stuck into one model.
These are changing quite regularly.
And there will be other models that are better.
There, one of the challenges we ran into,
when we were looking at the Funka project with we for authors,
is that you didn't have AI at your fingertips.
It was promised.
It could happen, but it seemed like that was something
that was only going to be available as part of a proprietary
add-on.
We can now build that in with open source tools.
There's a lot of opportunity using small scale,
small language models that can be incorporated
in very specific to our content management systems
to improve the content that we're developing.
So yeah, bundling stuff together,
looking at ways that we can build better prompts
and better systems to try and support more accessibility
out of the box for people who are creating
or editing content.
So a couple of other things in terms of shifting left,
which is a big part of the accessibility movement.
I already mentioned thinking about spell check in Sally.
There's also a tool called editorially.
Editorially is the one that's being built out of Princeton.
This built-in editorially is an integrated into Drupal.
It's sort of into Drupal CMS, not into Drupal Core,
but Drupal CMS.
And these are both tools that are fixing the problems,
many of the problems before they get into the introduction.
And yeah, if you fix the problems earlier,
you're going to save money.
It is way cheaper to fix accessibility problems
by catching them when the author is creating the errors
than it is a few months later,
when somebody comes up in a report.
Those reports are not useful if they're not timely,
because it takes time to go back and fix issues
that were addressed and forgotten about for months ago.
We want to try and find ways to empower users
and see this as being something that isn't another compliance
hurdle that they have to do,
because that's what the policy says.
But something that actually gives them
greater confidence about their ability to deliver content
that is valuable for their users.
We also want to have better ways to have cross-organization
accessibility.
So when you're looking at larger organizations
to make sure that you're using a consistent tone
or a consistent, how do we build the fact
that we have many sites in our organizations?
Sometimes they'll be like universities
or cities of hundreds of websites
that all have to speak to the same audience, the same user.
And we can use AI to try and help build a better user
experience for people, even for jumping across multiple websites.
More is possible.
I mean, all texts is an easy one in many ways.
Two years ago, I gave a presentation of Faustem
about Alt Text and comparing human generated alt text
versus AI-generated alt text, even for government websites.
Most human generated AI is not as good as what I've seen
already, what I saw two years ago with AI.
So that should be an easy one.
Captions and plain language and in simplification
content also useful.
I think we often think about ways of reducing friction
with technology, but I think we also need to think
about how do we increase the friction?
How do we find out how do we find those places
or we actually need to have authors spend the time
to do the thing to verify what they're looking at?
Just like the terms of service agreements
that we all skip through in-depth click on the bottom
and say, yes, we read this.
It's like, no, no, you actually, you have to read this.
You have to do the work.
You don't have to just scroll down and hit submit.
We need people to actually understand
that when you're dealing with AI-generated content
in particular, you can trust, but you have to verify.
Again, that's a Ronald Reagan quote, if you're curious.
So, yeah, and again, how do we provide
these structural support of hands
as opposed to, as people are developing things?
This is definitely a part of a science
but a very, it should be a rigorous process
of looking at how authoring tools are set up,
looking at the, also looking at evaluation tools
for sites that are built.
Are people here familiar with WKGEM,
the WKG evaluation methodology?
Not many.
Again, we should have a lot more people who know what this is.
Hitty certainly knows what this is, but they say,
because you worked out it for many years with WC3.
But this is an evaluation methodology
to try and ensure that sites that are built
are evaluated in the same way,
so that you have a consistent evaluation
with automated manual and human research to try and say,
how should you be evaluating accessibility?
How should your sites be ensuring
that they're structured and consistently evaluated?
And it's a really excellent approach.
I did in the talk and give a slight indication
that I was going to be using AI with WKGEM,
and I had hopes to be able to do that.
I didn't quite get there.
I did get to doing using AI to create an accessibility
conformance report, which is similar,
but it's more towards the USA, V-PAT,
voluntary product accessibility guidelines
for the framework and not in the same way as,
it's not structured in the same sort of format
as the WKGEM, but there are ways that we can start
using AI now to try and gather this information
to provide regular reports and to consolidate the information
so that we have a mechanism to be able to look ahead
in more quickly evaluate progress over time.
Because it's not, there's a phrase and accessibility,
like it's progress over perfection,
but we need to be proving progress over perfection.
We need to do this over and over again
and be able to compare results over time.
And all of these reports are things
that are going to need to be fed back into things
like the Web Accessibility Director
and the European Accessibility Act.
How many people have here run businesses
or a part of businesses?
And do you sell services to the fall into the European citizens?
So underneath the European Accessibility Act,
chapter 11.7, I think,
is chapter five, I think, too many different chapters.
There's a requirement to go off and start documenting
and organizing your accessibility.
What are your performance methods?
What are you doing to confirm that you're applying
to the European Accessibility Act?
We need to start looking at that and making sure
that we actually have documentation
about how we've, about the work we've done
to meet these accessibility requirements
and to comply with them.
So yeah, all these can be useful
to try and help produce reports that are necessary
for compliance, but it should be about providing
better content.
Before I talk a bit about that,
in terms of trying to automate it
and the challenges with this,
it is we wanted to be able to ultimately put things into a
adjacent format or some other machine readable formats
so that it can be easily read and consumed
and compared year over year with machines.
That's something that we need to start moving towards
and then it's great to see the WC3
starting to embrace that type of approach.
We also need to have more testing
and especially testing with users with disabilities.
I do not have a disability, at least not one
that stops me from using the web,
but there is a huge amount of value
from involving people with lived experience of disability
and hiring them to go off and to help ensure
that they can use the products
and that they can overcome all the things
that the automated tools will not see
because the automated tools are great
but they only catch about a third of the issues.
So I do want to challenge us to try and move together on this.
We've got a lot of different people
who know different tools and use them in different ways,
but part of what the WC3 author's cluster was starting to do
was saying, how do we collaborate?
It's something where the offering interface
is always going to be overlooked.
It's not something that generally people are going to pay for
and yet it is a huge part of solving the accessibility issue
because again, it's like spell check.
If we were running spell check like we do accessibility,
it would be nuts.
Like I think people would lose their minds.
And so, yeah, take a look at A-tag part B
and see if there's any you can apply to your CMS.
If you see the, if you're interested in learning more about this,
there's now a community group with the WC3
that you can join if you want to learn more and discuss this.
So I do recommend that you reach out to the WC3
and I've got links to all this in the resources which are next.
But do you take a look at the,
considering the A-tag approach
or so you're considering joining the A-tag community group.
You don't have to be invited to expert
to join that community group
and it's a wonderful place to learn.
I do want to encourage people also to share their work
and to talk with each other and to try finding ways
to go off and improve the accessibility of their interfaces.
Even if you're not a dribble user,
there's a lot of issues that you can look at in dribble
or even issues you can contribute to
but well, how could this be done?
What could we learn?
How could we fix this in whatever scene as you're using?
Also, that's a quick, provide a brief book announcement.
I wrote a chapter in a book on disability
and a digital accessibility ethics with a lady find gold
and a 30 other authors and it's not out yet.
You can pre-order it though.
I think there's links to that as well.
But I wrote a book on disability and open source
and trying to, except I did not include the chapter in this reference.
This is a bad, bad editing job.
But I wrote a book on open source
and accessibility and sustainability
and how these are things that we need to start working on together.
So I have, yeah, resources and link,
but most importantly, I have all the slides are online
and it's ox.ca slash p slash three, actually not four.
That's a lie.
Any other questions?
Excellent.
Thank you.
No problem.
I found it's a super expensive.
I am a bit too bad.
I'm too bad for you.
Perfect.
So, one minor comment and one of the
the minor comment is like, at the rules,
I have not, I do use A, A, A, A, A, A, but I don't know.
I have not convinced that they are really really about to talk
and maybe a lot can be done without them.
So I'm under this, but this that we did.
And the other comment is that, as you can imagine,
I am a net-vocate for accessibility like in real world,
where I'm worked.
And what I noticed from people is something very sad.
I think that they would like to that the care of accessibility,
so that in fact they can forget about it.
And this is, in fact, it took me some time to understand
that how painful this is, because in fact,
I value people taking care of it.
I value people thinking about it.
So yeah, I think my question is,
do you think this kind of truth?
Will more like help people to become more aware?
Or do you think that there is a risk of people just following
the two, but then disengaging, because they will completely rely
on the two for not having to think about it themselves?
I have about an hour of comments that I'd like to respond to on that,
but I will not.
So the question is, is twofold, one question was about AI
and AI trusting in AI to produce accessible content.
And the, is it necessary?
And the second one was looking at checkbox mentality
and how do we get over that idea that people just
want to get this done and don't want to go off and worry about that?
In terms of, is it necessary?
I think it probably is.
I didn't think it used to be, but I think that the rate
of change for accessibility, even after legislation,
is still so incredibly painfully slow.
And if we want to see progress,
then I think that AI in specific use cases can be good.
And it's not that AI is perfect.
The question is, is it better than humans?
And not the best humans, because it will never be better
than the best humans I don't think.
But it will be better than the average developer.
And I think in many, certainly with all text,
it's already better than the average developer.
Or the average content author at right now.
So for some things like that, I mean, absolutely,
I think it's necessary.
In terms of the checklist, I think it's a cultural issue.
I mean, accessibility, champion, as well.
In our organization, in other places,
I try and engage with people,
to try and change the mindset.
There's a real movement of people trying to be part
of building champions, movements,
so that it changes the culture from a checklist culture
to a, hey, how can we make this better?
How can we be excited about making our website,
our tools, our community, our staff, more accessible today
than they were tomorrow?
That we could be a better, more inclusive, more diverse,
more productive team, if we think about accessibility.
Even if it's just thinking about our future selves,
that this is something that will benefit all of us
if we make things, if we invest in accessibility.
But that's it, all right?
Thank you.
Thank you, bye.
Thank you, thank you, thank you.
I really, thank you, thank you.