Great, thank you everyone, I am Teeball, pronouns are he, him, I'm a developer and consultant
based in UK.
I just want to say a quick thank you to my partner who is looking after our kids while
I get to be here with you, so thank you Debra, I couldn't be here if you couldn't make
that happen.
And yes, a tag, whoever knows what that means, it's a big topic and I'm really happy
that so few people know about it and yet are in the room because it's a daunting acronym,
but it's certainly very valuable for us to be more aware of.
And it's like a bit of a dirty world to me in the accessibility world, to be honest, we
have to share examples of best practices, we have to talk about testing things to try
out the audits, like we'll get to the corporate side of accessibility later.
So yes, why are we here?
I thought at start, with a number 95.9% that's how many of the home pages on the web have
accessibility issues, according to the web I am million projects.
That's how the number evolves over time, as you can see, it's definitely training down,
which is pretty clear by 20, 15, 20, 20, 100s will be good.
But yeah, this is a big, big problem.
Those accessibility issues, they are only the ones that we can find with automated tools,
they don't even include the ones that you can find with manual testing, so this is just
playing an acceptable.
And yes, accessibility standouts, such as A-Tag, among many other standouts, I think we'll
help us to help us address this.
So just in terms of standouts, you might have heard about WCAG, or WCHD, that's the most
common to refer to standouts, that's lots of the legal frameworks out there are based
on, it's about making websites accessible, A-Tag is the authoring two accessibility guidelines.
So it's how you create better tools for people to create content that matches WCAG recommendations.
I hope that makes sense.
Lots of other ones, skip for today.
So why do we need authoring tools, super simple?
People just don't write HTML by hand these days.
They use social media platforms, they use their online blog that might have a WCAG editor.
Maybe they write HTML, but nonetheless they'll have a framework around it, they'll
have some linking tools, perhaps.
So all of those tools that help people create the content, whether it's web pages or videos,
live stream even, all those tools, there is a big, big opportunity for us to make them
better at creating accessible content.
So again, accessible is for the benefits of the users of this content, but the authoring tools
need them to be accessible as well for the benefits of people who create the content of the
authors.
And yeah, big concepts, I won't touch on, but I want to highlight, is accessible defaults.
So the idea that all of those tools, the default experience without you making too much
of an effort should be the most accessible one, then you can compromise a few ones, but
I really do too should promote accessible defaults.
So yeah, the standout, ATAG, our glance over the wording, it is a pretty big document.
There are lots of guidelines within it, and yeah, for today, it's just like too many to
fit on the screen.
You know, we'll just go back to the very high level list.
So back in, yeah, and all I care about really is the frame of the mental mindset of
ATAG is part A and part B. Part A is the authoring tool, whether it's the CMS or social
media, posting tool should be accessible, and part is it should support production of
accessible contents, and we'll be looking through all sorts of examples that help in both
cases.
Just to make it super clear, this is a screenshots of a CMS.
This is the content that's part B is about making more accessible, and part A is about
all this interface to the left, making that interface accessible.
So yeah, we'll look at part A and part A to be completely honest, a lot of it is just
full of the week I extend out for the web app that is your authoring tool.
So I only highlighted a few specific things that I think are interesting.
We talked a fair bit about alt text today.
There is quite a bit in a week I, about alt text and in ATAG as well, and I thought it
would be interesting to highlight how important it is when we discuss decorative images.
Inside an authoring tool, inside a CMS, all of the images are important, because you don't
know what they're going to be used for, so in there, actually it's much better if all
the images ever have quite lengthy descriptions, so people who manage the contents can
pick and choose as needed.
Autosave, I don't know who likes, I don't like Autosave, I'm actually a one to have
a very well-being data I stand over, it's actually an ATAG requirement, some of the cities
are strictly Autosave, there's no time limit to you being able to make your changes, that's
okay as well, but yeah, quite interesting.
Let's keep over the other ones, except for the very last, which is documentation, documenting
the features in your towing tool, that sounds super obvious, but is often forgotten,
and personally, I definitely feel emblems to ask my colleagues to work on documentation
or do so myself, if the rules say so, basically, and in the case of something like a
CMS, if we're mentioning, it's both docs for the devs who set up the websites, but also
docs for people who spend their time in CMS.
And so yeah, that's part A, part A, very short and sweet, and part B, we look at many more examples.
So I thought I start us with B.1, fully automatic processes, produce accessible contents,
what a mouthful, and all it means is, when there is some processing behind the scenes
that makes the HTML that people will actually consume, that process makes accessible HTML.
So I thought I'll show you an example of Google Forms.
You can use Google Forms to build web forms with arbitrary fields, it's a very simple drag-and-drop
interface where you configure the type of the fields and how they are set up, and there's
a very simple problem with it, which is that this email fields and this, what is your name
fields? Neither of these in Google Form. I can't define, oh, this is email, oh, this is the
person's name, so that person gets to auto-fill those fields. So super-basic feature of the web
being able to auto-complete a field on the mount, if you've already interviewed data in the browser,
in Google Forms doesn't support that. I don't know there may be some privacy reasons not to do this,
but definitely as far as A, that is the kind of problem we want to address, the fact that those tools
don't fully support making something as accessible as possible.
Second one that I really like, oh, this is a very small image, okay. Sorry about that.
So we are inside a master-down, the social media platform, and over the left here we have a post
editor, and that post I added an image. I don't really know if you can see, but there's a little
warning sign here that says, warning alt, that means I haven't added alt text to that image yet.
Obviously being able to add alt text to the image, that's just having that supported, that is
essential. But the tool reminding you that it's a problem that there is no alt text, oh, music to my
ears. And it's exactly what this specific week, eight, eight criteria is about,
facilitating the creation of alt text. And in this case, the master-down people have reviewed
like lots of social media platforms, they go above and beyond, because in addition to having
that reminder, the field that they offer, they also have this detect text from picture feature
right underneath. You can imagine how often people in social media put content images that have
text on them, and don't necessarily take the time to write that down. Well, that says quite a
bit of time, and helps people who consume that content have these alt text, which is essential.
Something else I want to highlight is another example from a completely different
universe, assist authors with accessible templates. Again, like, not necessarily the
class, what it means. But if you spend time interpreting this, it means that whenever an
authoring tool, like maybe a framework comes with built-in components, maybe a CMS comes with
built-in types of block content that you combine on the page. Those ready-made templates are
accessible, or at least you are assisted in knowing how accessible they are. So there's quite a few
certain more detailed guidelines within that kind of umbrella of B24. But yeah, I want to share an
example of something that WordPress does, where WordPress as a CMS, they supports themes for the
websites, and those themes in their kind of theme shop. There's a 109 themes here that are all
tagged accessibility ready. It's exactly what you want to see. So I think it's really interesting because
the WordPress marketplace isn't really authoring tool needs all rights, but definitely has the
place in the kind of journey towards someone creating accessible content with ready-made templates.
And yeah, so they don't put this arbitrarily, they have the expertise team for WordPress,
review those themes as needed, and tag accordingly to their best knowledge. And they're the only
project I'm aware of that does this, maybe some others do are there, it's really cool.
So another example of one of my favorite rules out there by far, I believe this specific tool
was referring to the screenshot here, Sally, that has been mentioned by Mike Gifford earlier today.
We're looking at assist authors in checking for accessibility problems. So it's this idea that,
again, we've seen the web, I'm million number. There are a lot of tools out there that can give you
automated feedback on your content. And that's exactly what ATAXA's should be embedded within
each and every authoring tool. I can't stress enough how amazing it would be if any single web framework
any single static site generator, any single CMS had this kind of automated checks built in,
like the web would just get so much more accessible in one go. And yeah, this specific one,
so Sally, we're looking at it on a on a block page here, it's kind of a little browser widgets
in the bottom right, and when you turn it on, it tells you, okay, I have one error and four
warnings on that page. Here we're showing the highlight of one specific error, and we're showing the
text for things that might require manual verification by a human. And yeah, super simple to integrate
this on any sites, by the way, so definitely worth considering. So moving on to one of the
of my favorites, assist authors in repairing accessibility problems, B32, and yeah, again quite a
mouthful, but it's kind of the next thing over. Once you've identified those issues with the
contents, well, what can you do? You can help people in fixing them. And you can actually introduce
some automation to make that simpler. So in this specific case, we're looking at alt text,
where again, Mike mentioned quite a few issues, and just like Mike, I spent some time looking at
sites built with this specific CMS, I'm not sure if you think too, assessing how the alt text
on those sites, how good it is. And so, the bar on the left, on each side here, that's the real
world alt text from about 500 pages. And that's the score that's the expedited team for a
white tail that CMS gave to this alt text. So on average, basically alt team rated the existing
alt text out there in the world quite low. And what's really interesting when it comes to repairing
this is we can detect quite often whether the alt text is good or not, whether it contains a file name.
And again, AI, quite a big buzz world, lots of things that I wouldn't necessarily agree with here,
but for alt text, it is in my mind undeniable that it is better than the existing content out there.
I definitely think that humans have a big part to play here. They could still write much better
alt text if they give an infinite training and time. But what we can do instead of rely on
AI actually write all of the alt text is give the alt text at the AI rights that scores quite high,
give that to humans and then that humans decide, okay, is it good? Can I be improving it? And it just
makes it for a faster process that has better results. So just to make it clear, like how
I would work in practice, now we're looking inside this CMS, what else do we want to file latest
designs that we've not implemented yet? We're looking inside an image upload feature where I've
just dropped a new image onto my web page. And it's going to pre-fill the title from the
file name, because sure that my big education of what it's about. And this description field here
is what people will be able to set for the alt text collaboratively with AI. So in this case,
we've decided to never pre-fill that fields. We've decided to give the user three different
options to choose from, but are distributed by the AI. And they can decide to use any one of them
and then edit the fields, ordinary, new suggestions. Again, like this is all quite easily aligned
with ATAC, so I find it's really interesting that standouts written so many years ago had in mind
this kind of interaction. Okay, we have about 10 minutes left. I'll try to end early, so we have
time to change over the devarums. But I definitely wanted you to give you some resources to
get started and we'll have time for questions right after this in the room. So getting started
with ATAC, again, this quite a daunting acronym. So definitely I'm hoping the examples I've shown
so far, they're kind of my highlights of the best bits of ATAC, which is considered reusing.
But if you did want to do a proper audit, this is where I would start. So step one,
definitely if you have a clear list of features in the tool you're testing, that's super
important because then you know what to test. Step two, having a good demo of those features.
So what I've often found is some of the more niche aspects of our CMS, find it quite hard to figure
out where to access them and it says quite a bit of time, you know, to be able to do this kind of
testing if I don't have a good demo really available. So I'm part of the accessibility team for
Django as an example, creating a better demo site for Django for the Django. I mean that's something
that's in my mind essential and worth the investment. Some knowledge of ATAC, I definitely don't
want to make it sound like you have to read through the whole thing. I think just the highlights
I mentioned is a great place to start. And then having an idea of how to report or keep tabs on your
findings. So I spent quite a bit of time ahead of this talk, setting up a GitHub project template.
I don't know here who might have heard of GitHub projects is something they've built on top of
GitHub issues and GitHub projects supports custom fields that are very convenient for this type of
very specialized work. So I've spent about an hour of my day setting up those two fields to keep
tabs off all of the weekag guidelines and all of the ATAC guidelines. So you can add things straight
to your backlog and tag them per which aspect of ATAC is about. Again, I can know it's quite a
specialist tool, but definitely just click this and you get to try it out and see if it works for
you or not. And for people who don't really like GitHub, I also put together Markdown templates.
It's a very big markdown file. So it works well, but yeah, a bit harder to adopt.
Okay, another quick and easy way to get started. So we're looking at the screenshots of the
ATAC report tool that was put together by the W3C web accessibility initiative.
It's essentially some kind of a form wizard that talks you through all of the ATAC guidelines
one by one and helps you fill in the results of your testing. So this would be really useful if
you wanted to do the full audit. But even without that, I think it's interesting to look at and see
if there might be specific areas within which I would offer you completing. I wish they did more
out of this. They put this together five years ago or so and it works really well, but I just
wish it was better showcased. And yes, when I say I wish they invested more time into this,
if you've gone through the reporting tool, the next thing you want to do after it's
share your report and I definitely want to see more reports of ATAC audits out there.
And they set up this authoring tool list to do that, where people who took the time to report
on the SVC of their CMS or research digital web framework, they are showcased on W3C websites.
And right now we only have five such authoring tools showcased because it does take quite a bit
of work to put those audits together. But if you did invest into this, for sure come talk to me
and help you out and consider, but you can submit your report to this site as well.
So yeah, just to end, going beyond those standards, if you ever feel like even ATAC isn't enough
for you, I would recommend you look at these two that are attempts against standardizing this kind of
increasing of the baseline of accessibility. But the same with the guidelines, the touch on
points, a lot of aspects of what this dev room is about, and I submitted a trading model,
that's kind of a national level where other gaps what we should do. I'll leave these there for you
to consider. And yeah, that's me and I believe we have about four minutes for questions, thank you.
Goodfights.
Three, two, that's a lot to make the end, three, zero, one, five, five, nine reports.
Can't tell me where it is, but no. Well, there, yes, there's one.
There is a big invention benchmark for my work. So for Ian, I forget the European standard for
accessibility, that's based on weak act but does beyond. There is something called open ACR that is
set up by the US government, GSA, and that's meant to help you create reports for section 508s
or for the European standard, and they come with the Open ACR editor. Hope that helps.
That's something I have mentioned at the beginning, but a problem, I have a problem of this
for the short, kind of little characters. And when it's a many website, when I put control
through the entire box, the text is going out, the screen, I think a single idea must be
some console, it's not normal to have this kind of thing, it was price, you know, I try your
thing, and so on. Yeah, that's covered in the weak act standard, and as also covered in
ACR, as far as this issue happening in the authoring tools themselves.
Any more questions? Great, thank you. Handover to Sarah, to say a quick goodbye, and then we'll
handover to the open source design platform.