So everyone, welcome back to the Open Web Alliance Dev Room.
Oh man. Cut that bit. Cut that bit. Welcome back to the Open Web site Alliance.
Open Web site Alliance launched today. So I'm allowed to practice it saying it three more times before it has to be free of mistakes.
So in this Open Web site Alliance Dev Room, we're now going to proceed with two friends from the Type 3 community and from the Mitwald hosting company talking about accessibility and content management systems.
And they are going to be so kind and work their way in over the next 40 seconds to get started talking. Please Martin and Lucas.
Alright, thank you so much. Thanks for the intro. Good morning. Can we still say good morning? It's before 12. Yeah, we... Alright.
Alright, good morning everyone. We're going to be talking about accessibility and content management systems. We're going to get back to that bit in a second.
I'm Martin. I work at Mitwald, responsible for developer relations over there. In case you don't know Mitwald, we're a hosting company from Germany.
We specialize on providing the support for agencies, mostly in the open source CMS space. I also do some lecturing on computer science.
And just a little disclaimer. I only have started learning about web accessibility recently, most of which I know I actually have learned from Lucas who's standing right next to me.
Yeah, I'm Lucas and accessibility is quite a personal topic for me as you might have noticed already.
So I have personal experience with a lot of issues you run into if you have some accessibility needs.
And I'm a project developer at Mitwald, I think four years I started at Mitwald. And about ten years I'm a freelance web-based developer and developed themes, plugins, custom solutions and stuff like this.
Yes, and I have advocated for this topic in our company for a long time now and now it's starting to get some action. And so we are here and talking about accessibility today.
So I think or I might speculate that one reason this topic has been gaining traction in the past few months, years is that there's new legislation coming up.
Like for example the European Accessibility Act comes into effect I think next year. There are also other laws that pertain to the same direction like in the US there's the Americans with Disabilities Act which has been around for a while, I think since the 90s actually.
So I think this might be a reason that some people start seeing this now. But in the next 30 minutes we actually plan to convince you that fear of legislation should not be the actual reason to consider accessibility as something that's a good idea.
Because in actuality it's about enabling access for everyone and not getting sued should not be your primary motivation for this. Like in a perfect world we shouldn't actually need to have these laws.
So it should just make natural sense to be as accessible and inclusive to everyone.
Sorry, I'm getting confused.
To understand what we are talking about today we first need to define some things and mostly there are different kinds of barriers you can get to if you have some accessibility needs.
And we've listed some here on the slide in a second.
First of all there are perceptual difficulties you can get. For example if you have some vision and disabilities, a lot of you wearing glasses, discounts as well.
And all of you have heard about color blindness by now, contrast issues and stuff like this. These are the most obvious things a lot of people think about.
But there are motoric issues as you can see. I mainly use my right hand so it's difficult for me to do stuff like a lot of keyboard shortcuts are quite difficult.
And stuff like this or maybe you have Parkinson disorder and you can't do small movements or keep your hands still. This is another problem.
Mental and cognitive issues I think all of you have heard about ADHD.
It's difficult to concentrate for people with ADHD if something is moving on your website or even on slides.
Yesterday as well as the slide where an animated GIF was running all the time it was really hard to concentrate even for me.
And someone with ADHD would have really, really much trouble concentrating on such stuff.
And videos or animations on websites, it's the same issue. So think about this when doing such stuff.
Remembering stuff especially in our short time memory might be quite difficult for some.
In marketing there's the rule to just put at most eight items in your menu. This is one of the points so think about this as well.
And then there are two more topics we want to talk about because there are also technical and economical aspects to accessibility.
Maybe not all of the people want or can buy new devices, a new smartphone every year or because of environmental reasons they just don't want to.
So technical accessibility is a problem as well.
And maybe your TV we have some TVs in our company which has very low contrast ratios.
We're actually in secret hoping to have one of these fitting university beamers just to bring across the point better but actually turn out to be alright.
But you can see it in the top right corner. The Mid-World logo is quite difficult to see because it's white text on white background, not a good example.
And maybe you have one of the famous low internet connections in the famous Deutsche Bahn.
Then you will run into trouble as well.
Yeah and of course low-end and all the devices I just talked about and you have to keep in mind that sometimes financial problems correlate to physical disabilities because people already have to spend much money on accessibility devices like wheelchairs and stuff like this and don't have that much money to put into technical devices.
I think disability also correlates with unemployment a little bit.
And if it's not a disability as mine you might also have a disability sometime.
Maybe later your eyes get worse or you have a temporal disability, a colleague of mine tore his Achilles heel last year I guess and suddenly he noticed how hard it is to get up the stairs at the office.
So everyone could be affected sometime or even if you just hold your coffee cup in the kitchen suddenly you only have one hand to use your smartphone and such stuff.
And a lot of you might be the kind of keyboard nerd who likes to use the terminal for all his stuff and such.
And such people will be happy to use your website only by keyboard as well.
So accessibility needs can always be a personal preference.
Yeah so with JusticeCast there are a lot of aspects you have to think about.
Some of you might think this is really expensive, this must be really hard work.
But in fact it's not that difficult.
So I think about many people think about like adding accessibility after the fact which I can imagine does get painful because there is a development effort in that.
So obviously the most obvious recommendation would be to just consider accessibility from the start if you're starting on a green field.
Then it's actually not that difficult if you think about it from the get go and just think about it as a quality measure.
Like you would also think about code quality.
I'm guessing who's a developer actually.
So most people, I would guess most of you wouldn't also think about skipping testing.
That would be insane.
And really irresponsible wouldn't it?
I see some people struggling.
Like who would do that?
And even if you're arguing about money, if you're building an inaccessible product you're actively excluding users from your product.
And I think there's estimations it's potentially about 15 to 27th percent of users that you're excluding.
So if you're taking measures to include these users that's going to pay for itself in profit.
And even if you're not starting on a green field there are also synergy effects with other quality goals.
For example we've talked about sensory issues.
For example if you have a limited vision or limited hearing and you provide audio content like podcasts or video streams.
And one measure that you could take is to provide a transcript for that, for your audio content.
Now if you have a transcript that's text and a search engine can crawl it.
Boom! Instant SEO.
We've also talked about accessibility issues on lower end devices.
Because not everyone wants to buy a new iPhone 15 for 1500 bucks every year.
I don't want to.
So if you're targeting lower end devices you need to start thinking about limiting resource consumption.
Being more efficiently you need to start thinking about performance optimizations.
Which in itself is also an important quality goal.
Which I'm just thinking about now is that this also has a sustainability impact.
Because you're enabling users to keep older devices longer before they need to be replaced before they become obsolete.
You also minimize resource consumption.
You also minimize battery drainage on mobile devices for example.
So that's also an important synergy.
There are some quality goals where it gets a little bit more complicated.
So for example when we talk about security there might be some trade-offs that you need to make concerning accessibility.
I think a general rule of thumb might be the higher your security requirements are,
you need to start thinking about accessibility to not become a problem.
For example if you're enforcing multi-factor authentication you need to think about a way to make that accessible.
If you're in even higher security areas like if you want users to use TLS client certificates or some things like that.
That's a very high cognitive load that you're placing on users.
Last week I used my German EID card for the first time to log into a service.
That's not for everyone.
I honestly have no idea if there's an accessible way to actually do that.
This is not an impossible problem.
There are guidelines for this and I'm just skipping a little bit ahead to the actual solutions.
There are guidelines on that and there are guidelines on accessible authorization.
Most of these boil down to reducing cognitive load on authentication.
The recommendation is that your authentication process should not be dependent on a cognitive function test.
Who remembers those?
This is...
Can anyone of you solve this? I can't.
This is just ridiculous.
Luckily these have gotten a little bit out of fashion lately because probably at the moment AIs can solve these better than we can.
There are ways around that.
It starts with simple things like if you have a username password.
Remembering a password is also a cognitive function test but you can use a password manager.
You can copy paste the password into a password input field.
Don't prevent that.
You remember those password forms where you can copy paste into...
Yeah, that sucks.
If you're requiring multi-factor authentication, I think there are new standards coming up that we can use to make it more accessible like web authentication, like pass keys.
All of those reduce cognitive load on the authentication process.
So that are things we need to start thinking about and need to start thinking about implementing them.
And users without disabilities also benefit from pass keys, for example, because it's just a matter of comfort for those.
Absolutely.
Now let's talk a bit about cognitive management systems because this is why we are here.
And in cognitive management systems you have two sides of the same kind, I think.
On the one side you want to provide accessible content to the end user, so to speak.
So one important part is that our editors have the option, the possibility to create awesome and accessible content at first.
And of course the editing experience itself, so the backend should be accessible as well.
So that the editors itself with accessibility needs can edit the content.
And think of a blind user who is trying to create his or her own block and share their experiences to the world.
They need to use a cognitive management system.
Yes, for the front and sides, so to speak, there's the web content accessibility guidelines.
This is the most basic stuff I hope most of you might have heard this by now.
It's things like alt text for images, using anchor tags for links, using semantic HTML, I will run about this in a second.
And then there's the editing side, there's the authoring tool accessibility guidelines.
This is especially important for CMS systems.
We won't go into detail on this because everything you need to know about this, you will read in the documentation.
But we want to highlight some of the most important things.
One of the most important things is using semantic HTML.
And I would hope this wouldn't be necessary to say these days, but a lot of people get this wrong still today.
Use a semantic HTML on the screen, you can see the header and the nuths who have replaced this in HTML5.
But it starts with the basics.
Use list tags in your HTML if you mean this is a list.
You see in the wild you still see a lot of paragraphs all starting with a dash.
This is garbage for screen reader users. They can't use this.
So please use semantic HTML and most importantly make it easy for the users of the cognitive management system to use this semantic HTML.
Maybe provide some automatic functions like if a paragraph starts with a dash automatically converted to an unordered list, you can skip to the next.
And provide such automatic features.
A lot of you might use some messages who do this by now.
And our CMS should do this as well.
I think a good example for how this really works out is this is a screenshot from the word for spec end.
Where you have this semantic outline view where you can actually see the hierarchy of your headings.
And the system also points out where you did something where you built it inconsistently.
And this is really important to enable editors to build consistent content structures.
Because screen readers actually built on those.
I think Jaws is one of the most prominent screen readers.
It actually offers navigation options based on the hierarchy of headings.
So if you mess that up you're also going to mess up the screen reader.
So I think what CMS in general should do is to discourage users from just placing certain kind of headings for aesthetic reasons.
Because people do that.
I see and through the yes, the nodding.
Yeah.
So there should be ways to discourage that even if it's just pointing out where things went wrong.
And we also need options to be able to configure the CMS to prevent users from doing that.
Like this is a screenshot from the type of three backend.
In which as an integrator you really need to know how to configure the system to prevent users for example from.
Above there is the content element heading which is I think in the default distribution it's rendered as an H2.
But nothing prevents an editor from inserting their own H1 into the body of the content element itself which will mess up the hierarchy of headings.
You can disable that as an integrator and you should but you need to think about it and you need to remember it.
For example the Gutenberg editor in Watpers and they also have the option to set as custom H1 heading.
And for the websites I develop I mostly disable this option deliberately so the users who edit the pages cannot make this one by accident.
I think in general there are some parallels to search engine optimization aren't there?
Because if it's a screen reader or a search engine you need to be able to build your site in a way that a machine can make sense of it.
And that's why it's so important to adhere to.
Basically it all boils down to adhere to the standard.
Another thing that we'd like to point out is users are going to have certain expectations around how a system works.
I read a case study a while ago on the type of 3 block.
I think CPS did it.
They tested the type of 3 back end with 2 or 3 blind users.
And I think the gist of it was that you already can use the type of 3 back end right now with a screen reader if you have received appropriate training in doing so.
So if you're in that situation you're going to have...
You're relying on the system working in the way you were trained and you're expecting it to do.
So the most important thing is to not break the expectations that users place upon the system.
This goes in very, very, very many different ways.
One example are conventions around the menu structure.
Each and every CMS back end has some kind of menu structure and there are conventions and there are expectations around where things are placed in that menu.
This especially gets important when we're talking about plugins or extensions or modules or whatever.
Many names, same thing.
Because we're not only talking about the CMS course, we're also talking about the ecosystems around the CMS, the third party extensions that extend those systems.
So what we thought of as important is that extension authors should be encouraged to adhere to the conventions that are applied to the navigation structure in the CMS back end, for example.
Another thing are UI components, for example.
I think there are some WordPress plugins that completely roll their own UI library that behaves entirely different than the rest of the CMS.
If you're relying on having your expectations around how the system works being met, then this would really confuse you.
One other thing is clutter.
I think this is a screenshot from a fairly representative WordPress back end.
This is the plugin list.
Let's have a look at this.
That's a feedback prompt.
That's another feedback prompt.
That's an add.
That's another add.
That's a maintenance message.
We talked about ADHD, didn't we?
I also don't know what would happen if you would pipe that through a screen reader.
I honestly don't know.
Nothing good, probably.
This is another screenshot.
This is the WordPress...
Was it the same site?
Yes, it was the same site.
The dashboard itself, same site.
The same feedback prompt.
Another feedback prompt.
Another maintenance.
That's an add.
That's completely useless.
I want to point out this new section is from the podcast plugin in this installation.
The news in this widget are about digital cameras, YouTube videos.
It's nothing about podcasts.
You can disable all those as a user,
but you're still being confronted with the cognitive load of...
You need to make sense of it at least once.
You can disable.
This is the perfect handover to my next talking point.
It's about giving the user the choice and respect choices the user has already made.
As you just saw in the WordPress dashboard, users can disable the widgets in the dashboard,
but there are a lot of more choices the user has already made when using your system.
All of the operating systems nowadays provide some kind of dark mode, for example.
It's really easy to use the dark mode setting in the CSS you can click, I think.
We messed up the order in this list.
Another point is opening links in new tabs.
I often see that suddenly a new tab opens.
For me, this is quite normal because I know the tab system.
I'm used to this, but when giving courses to my clients, I can see that they get often confused.
Once it was some worker in a school, I think, she tried to do something in the WordPress backend.
A new tab opened. For me, this was obvious.
She tried to use the back button of her browser, and she didn't get back where she was before.
Her solution was closing the browser window completely and starting from scratch.
This was pain in the ass, not good use.
I think my mom would do that too.
Of course, a lot of people do this because they don't use the PC or the browser that often as we do.
Think about these users.
Give the user the option to open links in new tabs.
All of us could just hold the control or command key, and other users might use a wide click open in new tab.
Give the user this choice.
He or she knows when he or she wants it.
Now I have two clicks, so I can see my next point.
The user can select a font size, a minimal font size, and the browser settings.
This is very important for people wearing glasses, or maybe later if your version gets worse.
We have a colleague whose IDE is set to 48 points. It's really, really large.
You might imagine, but for him, it's the best way to code.
The IDE respects this choice, and so should you on your website.
Just the other evening we were reminiscing about building websites in the old days.
Do you remember when websites had their own buttons to adjust the font size on the site?
You remember that?
Something to do.
That's completely attributable because the browser does it for you.
You don't work against the browser.
I'm the next talking point I already talked about before.
It's a reduced motion and video auto play. Just don't.
I think every one of us is annoyed by auto playing videos on news pages.
It's the worst stuff.
A reduced motion is a CSS property.
Maybe you can click through so we can see the CSS snippets.
The browser these days implement the choices you can easily opt in and reduce smooth scrolling or animations if the user has chosen to do.
This is minimal effort, but a lot of users will benefit from this.
Increased contrast and color version.
I've already talked about this.
Just think about that some colors might have the same gray value, so to speak.
Once during my college lessons we had another student who asked my professor what this large circle on the slide is about.
It was a pie chart, but all of the slices of this pie chart had different colors.
It was obvious for us, but for him it was just a gray large circle.
Because yes, he can only see gray scale. No colors at all.
We didn't know this till this moment, but for him it was really difficult.
One thing I always went about when trying to play some games with my friends is I'm casting keyboard bindings.
Some games allow you to change keyboard bindings.
Some games don't and some of these games I just cannot play because I can only use one hand when gaming.
You still beat me every time in each of these games.
Yeah, sorry.
Maybe give the user the option to set some keyboard bindings even in your CMS.
This could be customizable.
Think about such stuff.
It really, really helps some people.
Yeah.
This is an argument I also hear quite often.
Thank you.
Image with text in it is not readable by the search functionality of your wiki.
Much into the technical details of accessibility.
Our goal was to basically make you think about why accessibility is important and what it's actually supposed to solve.
I'm seeing the animation order on the next slide is going to be messed up. Apologies for that.
I would encourage you to think about accessibility not just as a feature that your PO can throw into your backlog and you can tell yourself that you're going to build it when you have the time, even although you already know that you're not.
Please also don't think about accessibility just as risk avoidance so that we don't get sued.
So if you want to think about accessibility as anything, just think about it as a human right that everyone should have and enjoy.
It's just about making your product as accessible and as inclusive as you can for everyone.
And there's the last animation step I said the order is messed up.
All the technical stuff, all the accessibility guidelines, you can test this.
There are automated test rates, you can pipe it through light holes and light holes, gives you a green check mark for example.
But don't add accessibility just to have that green check mark, you need to understand what you're actually doing it for.
Thank you.
I didn't drop it.
Wonderful. Congratulations. Thank you very much.
In my experience, thinking about accessibility, two things really surprised me in my path.
And the first was the realization that there are temporal moments where we're all less abled.
Like walk out into the bright Brussels sunshine and look at your phone screen or carry anything or have a child or you know.
So I found the idea that we're all in that category on a sliding scale all the time, really interesting.
And then as a marketer actually, accessibility, if your motives are not pure,
and not moral, and not ethical for a second, your total addressable market for any given thing goes up by including more people, right?
And if you, and the more semantic data, the more machine readable data you have is the more
accessible, is better for SEO, is better for making sales, right?
So there's no cogent business argument in my mind to not making accessibility, right?
Yeah. So any questions for the, from the room before we break for lunch?
I'm sorry, I'm sorry.
I'm sorry.
Any questions for the, from the room before we break for lunch?
Yes, please.
You should never mention lunch.
Unless your question is what is for lunch, because I don't know.
So the question in, and the question was if it's a bad thing to, to provide dark mode
for the user, and the user is not allowed to use it, and the user is not allowed to use
it, and the user is not allowed to use it, and the user is not allowed to use it, and
the user is not allowed to use it, and the user is not allowed to use it, and the user
is not allowed to use it, and the user is not allowed to use it, and the user is not allowed
to use it, and the user is not allowed to use it, and the user is not allowed to use
it, and the user is not allowed to use it, and the user is not allowed to use it, and
the user is not allowed to use it, and the user is not allowed to use it, and the user
is not allowed to use it, and the user is not allowed to use it, and the user is not
allowed to use it, and the user is not allowed to use it, and the user is not allowed to
use it, and the user is not allowed to use it, and the user is not allowed to use it,
and it is a struggle for dark mode, for example, but the default option should be to option
the user as chosen.
Yes.
All right, so, thank you very much.
Thank you.