We have Danny and Maximilian talking more about accessibility, so take it away.
Thank you.
Hello, everyone.
We have this talk with lots of nice acronyms and we hope you enjoy it.
We will talk about accessibility today and about how to make your web applications more
accessible or with some easy tricks and make it accessible to everyone.
And we are Maximilian and I'm Danny, we are from Deutsche Bahn, it's a German railway
company and we are both working in frontends, working for web applications, yeah.
So we want to start with a site from Bill Clinton.
It says congratulations through the launch of the web accessibility initiative, an effort
to ensure that people with disabilities have access to the Internet's worldwide web.
And did someone of you guess from which year this site is?
I would just give it.
Okay, it's from 1997, so accessibility is not a very new topic, a very new thing.
It was still there every time.
And yeah, we want to start a little bit with the awareness of accessibility, why it matters.
Then I will say something to some implementation things and then how you can ensure your application
is accessible.
Great.
Thanks a lot, Danny.
So first of all, accessibility, and we heard the talk by Mike, it was really amazing to
see so much, even also regarding Drupal and all of the open source CMS, for example, the
development over there.
But when we talk about accessibility, it's quite easy to say that it's only about a specific
group in the end who would have disabilities and even also already said something about
it, it's really about including all the people in there.
This is the main paradigm in the end.
But even also, it's us as developers who are bringing in the barriers, who are bringing
in a nonresponsive layout in the end, who are bringing in something which doesn't work under
different circumstances.
So this is something that we even also want to dig a little bit more into detail today
and show you some things regarding those aspects.
So you might, again, you might think of blindness, first of all, but it's about so much more.
It's about permanent disabilities, it's about temporary disabilities, and even also situational
accessibility issues in the end.
There might be, you might have, for example, you might be in a situation where you do have
probably, for example, your child on your arm or where you do have only one arm, even
also for controlling your device.
It might be a light condition in the end.
There are so many more things than just this one thing that we might think about quite
easily in the very beginning.
To come to the topic why it's even more important is it's a legal topic.
There is the European Accessibility Act, who was enacted in 2019 even already, needs to
be even also transferred to the law in each country in the European Union, in Germany,
for example.
It's even already lost since one year now, 2021, two years, sorry, 2021, but for example,
they will only penalize this until the beginning of the year 2025, but it's similar to GDPR.
We even also, like, we waited for a long time and didn't think it through, and so many companies
only started to think about and to enact on this topic when it was quite near to the
state in 2019, I'm sorry, with GDPR.
To clarify things up a little bit about the structure, how it's being managed, how, especially
for the web, and we're mainly talking about the web, there's obviously even also accessibility
regarding applications about native development, so the structure is obviously in general,
it's W3C, and they do have a web accessibility initiative, WAI, who's formulating those web
content accessibility guidelines, so these are kind of some words that we're even also
using in our presentation in the end.
So all of these rules, all of these principles divide into four categories in the end.
There are, I think, 60 or 70 principles who are divided into those four fields, so it's
about perceivable, understandable, and robust criterias that you could test, for example,
your website against, or that you could ensure the compliance of your web pages, of your
website or web application against.
And even also, those play up into three conformance levels.
We've listed them over here.
It's about that A is really the basis, and it should be ensured in all circumstances,
like, for example, about providing alternative texts in the end for your images.
This is probably quite a simple one.
It's, and the other two criterias, this is about really dividing in between, for example,
governance, who need, or governmental services in the end, who need to ensure that it's about
these AAA criterias that need to be followed in the end, and, for example, for private
companies it's most likely about AA that they need to follow.
And all of those criterias are like structures in those conformance levels.
Why isn't it important in open source projects, you most likely all know this image.
It's always used in kind of the context of security, for example, but it's even also
similar.
I mean, accessibility is even also some kind of a quality attribute in the end, which is
underlying and attribute on something that you could even also use for accessibility.
So if you do have an inaccessible UI library, for example, or if there's something that
is inaccessible in this UI library, it might lead to problems in so many more projects.
And the general paradigm about this is if there's even only one accessibility issue
on the website, it's inaccessible.
It's not about the amount, it then is inaccessible, and that's very important in the end.
You need to test it and you need to, for ensuring this, it should be inaccessible.
And that's why it's so important, even also to test your stuff, but even also to contribute
if you do find something on the Internet to contribute to those libraries.
This might be groundwork for many other websites in the end.
So just one simple commercial about us, about Deutsche Bahn.
We even also do have a design system at Deutsche Bahn.
And we obviously, in the very beginning, we started as Inner Source because it was kind
of a small initiative, obviously you only have some developers, you have some designers
over there.
But then we thought about quite quickly to go Open Source, because from my point of
view, I'm even also doing privately, developing some polyfills and that stuff.
I think Open Source is one of the paradigms, it's about learning in public, isn't it?
I mean, it's going out, it's talking to each other, it's about really getting feedback
and that stuff.
So we decided quite early to go Open Source and get feedback from the public, even also
to get that information.
So I'll lead over to Denny then for the implementation part.
Thank you.
So now we want to focus on what's important when implementing an application on your
iLibrary, what's the most important thing?
And the most important thing, the really most important thing is use semantic HTML.
So that's really the most important thing, I can't say it often, so it's really, if you
only use diffs, then you make things much more harder to bring in accessibility later.
So to make your application accessible later, it's way harder.
So it's easier to change the button style of a button than to bring in accessibility
to a diff element.
And a very big thing is that you use landmarks.
So landmarks are used to structure your web page to big elements.
So like a header, like a navigation, a site container, main part, and the landmarks are
very important for screen readers to identify where is your structure of the site.
So where is your navigation, where can I switch the sites, where is my main content?
And this makes it really more easy for users of screen readers to find the content and
to navigate between them.
And another thing is the headlines.
So when you use headlines, be sure they are in the right order.
Don't leave out some levels of the headlines or mix the levels.
So just don't make an H1 and after that an H5.
So the headlines are like in a book.
If you open a book and you have the index, so you can just, your web page should be structured
like a book.
And another thing are buttons and links.
They're often, often people just use buttons and make on click handlers and the on click
handler will navigate to another page, which isn't a good thing.
So please use links to navigate to things and use buttons to do things, to make actions.
And please don't use this.
So never.
Forms are also a great example where accessibility matters a lot.
So you have separate elements in the structure of HTML for the label and for the input field,
but you should link them together using the ID attribute and the for connection.
And you also can use area attributes to give another hints.
This is probably the sun, yeah, a great example of accessibility.
So yeah, you can use descriptions for more hints which are read out by a screen reader
to the users so that the users know, okay, this description is linked to this input field
of my form.
Yeah, and the attribute is also very important.
It's not an art tag, by the way.
So it's an art attribute and yeah, it should always, sorry, you should always use an art
attribute to describe what's visible on an image.
So it's very important that people who can't see an image that they know what it describes.
So the only thing when you should use an empty art attribute is when you have just like a
decorative image.
Like you have a disk icon for a submit button and the submit button already shows that the
text submit, then it doesn't make sense to have like more content.
So yeah, but otherwise describe your images.
So modal dialogs, also a great example, there are lots of UI libraries in the web which
are not accessible and lots of UI libraries implement like modals from times where the
browser didn't support the native dialog element and these libraries have a big issue because
when a modal appears sometimes a screen reader will not notice there's a modal and will,
so it will read out the content behind and that doesn't make it accessible.
It's not good.
So the native dialog element is a really good way to use and to make your application and
especially modals accessible.
And there are other cool things which are not only good for accessibility issues.
As you can see this is a detailed summary element in HTML and it helps also because if you use
like command F or control F on Windows and search for a term it will automatically expand
and will show where's the content inside the summary, the details.
So yeah, that's also a good example for semantic HTML elements.
And there are other things like auto completion for data lists.
So there are a lot of things that got more and more standardized and are available in
HTML5 now and can be used by developers to implement which makes your application more
accessible without using area attributes.
So area attributes are a way to, it's like, if you don't find a semantic HTML element
then you may have to use a diff and then you can think about do I need some area attribute.
There are some area attributes which helps for making things that aren't natively accessible
that helps to make them accessible.
For example, if you have an area life attribute it helps to read out, if you like, have notifications
on your site.
When you get notified from a server or something a message appears then you have to find a
way to tell the user there was some message occurs.
So therefore area life can be used to read it out for screen reader users.
And now may you asking how can I test easily that my application is accessible and I will
try it over to Maximilian.
Yeah, thanks.
Thanks, Denny.
So one thing that I'd like to quite quickly add to what you said, think of those HTML
tags like little micro front ends that the browser delivers to the user without the need
for JavaScript, it's there even already.
We do have poly fills for most of these features even already.
So use them and by stabilizing this stuff even also through the browser vendors we might
get better features in, we might get better features even also in the future.
Like for example on mobile devices you might get a different UI, you might get a different
keyboard or even also what we've shown regarding details in summary.
It might be something that the browser vendors then could innovate on and for example bring
in this cool feature regarding site search.
So QA in testing, we had this question previously regarding testing.
I think one of the easiest things is really to use, let's say easiest things.
You do have the keyboard in front of you most of the time.
So you could use the keyboard, use the tab key to try to navigate in the application
that you're responsible for, that you're working for in the end and try to reach all of the
interactive elements in there.
Try to control the navigation for example, try to see whether the focus is existing for
example.
There are so many things which are related to keyboard controls even only on the page
where we do assume that the users are using a mouse but this is even also something that
is beneficial for screen readers even also.
It's obviously not something that is the only part, screen readers is even also what Danny
talked about regarding semantic HTML but if you do see that it's not controllable by keyboard
it's most likely even also giving screen reader users a hard time in the end.
And this is the easiest one.
We even also talked about, Mike talked about some other tools we like to highlight at least
Chrome developer tools.
They do have some really nice stuff especially for contrast ratio for example.
We wanted to highlight over here.
They do have Google Lighthouse where you could obviously measure so much more stuff but they
do have an accessibility section in there even also giving you great tips in the end
and they even also provide you insights into the accessibility tree which is the basis
for rendering that stuff later on or telling it to the screen reader.
There was a great talk yesterday by Mozilla even also on optimizing this regarding performance
and accessibility performance.
I would really suggest you to have a look on the recording for this one.
Another part is the X DevTools.
They do have something for CLI even also.
They do have plugins for the browsers.
Why have we used the Foster website over here?
No hard feelings.
I'm sorry about it.
Total issues 35.
Yeah, let's skip that.
Next slide.
Still, it's about the same message.
It's about the human's test with humans in the end.
Keyboard is something which gives you some insight quite quickly.
It's something that is really low level in the end.
But talk to colleagues in your company in your field in the end.
I'm even also working with several colleagues with disabilities and was really inspiring
in the end to see how all of this works and to go through this stuff.
This is something that is really important.
Talk to the users in the end who are using this.
One of the last things previous to the questions that we wanted to bring up because we talked
about it, we had a quick conversation about it.
We do know CVEs, for example, for a global database regarding security issues.
Why don't we even also do this for accessibility vulnerabilities in the end?
Because it's even also something that is becoming or that should become more important
and that even also becomes legal.
So why not do something similar for accessibility and we leave you with this.
Thank you very much for your attention and let's go over to your questions now.
Yes please.
I could repeat it.
There are some elements for some of the data picker that is not accessible by default.
So they are catered where you should have to have the UI library.
Do you know some reference documentation that you can report to?
It depends on the, I would say, sorry, I should repeat it.
There are some elements in the end.
Yeah, sorry.
There are some elements, the question was, there are some elements like for example the
data picker which are currently even already identified as not being responsible in even
the native browser implementation.
So I think, and the question was about whether I do know libraries which I could, for example,
recommend.
I think in the end it's depending on the context that you're working in.
So for example, if there's a great Angular plugin, you couldn't use it in React context.
So you always need to sadly do the research and search for a good plugin.
I think, and I talked about the standards previously, I think it's so important to
you to support those standards because if we do standardize all of this stuff, then
the browser vendors do have the chance even also to make things better in the future.
This is the main point.
So I couldn't necessarily give a perfect suggestion at the moment, but I do know about
those issues at least, they pickers.
It's quite hard.
There's another initiative who are trying to even also come up with new solutions because
even also most designers think about that these ugly, let's say, ugly standard elements
in the browser that we need to overlay them because of design reasons.
And there's another initiative.
I don't remember the name who are even already coming up with something, for example, for
the select menu to build this new, but again, I'm sorry, I could even also, we could add
it to the slides afterwards and then it's in the, add a link on the Foster website.
Yep.
Thank you.
Any more questions?
Yes, please.
Yep.
It's you.
Pablo.
My impression here is that by the time a developer has a chance to do that, it's committed
to it.
At Deutsche Bank, how do you approach this from a design perspective?
In the UXUI, but in general, as a designing the product, before even a developer has the
chance to say, actually, I know how to do this in a way that will pass a test.
Yeah.
Because that is the beginning of the funnel.
But if we don't do that properly, so I'm curious about your experience that instead of focusing
too much on when it's already there and the developer has to do some needs AAA checks.
Yeah.
So I do even also say the question again, how do we approach accessibility not in the end,
not a testing, but even already like, for example, in the concept phase and design process exactly.
So I think it's mainly about to have this scaling in an organization.
It's only the first most important thing is about awareness from my point of view.
So even already in our onboarding sessions for new employees, we are having onboarding
sessions, we do have talks, we do educate on accessibility even already.
So I think the main thing is about awareness for all involved people in the end, for product
owners, for designers, for developers, for testing in the end.
I think it's mainly about awareness, I would say, and then you could only scale.
And I'd like to thank you for your product because we're really looking forward to your
product.
You talked about thank you.
Yeah.
So another question.
Follow up.
I'm afraid it's not only about awareness.
I think it's also about the right skill set.
We are really struggling to find a talent, accessibility talent in the design space.
Awareness is fine, but it's also about experiencing really challenging projects.
Totally.
It wasn't about only aware.
I know.
You haven't said it.
So I repeat it quite quickly.
It's not about only awareness, it's even about the skill sets.
It's about experiences.
But you need to start somewhere.
I mean, you could build up experiences by starting and then having all the people getting those
experiences in the end.
I think I couldn't have a better answer at least.
We do have several teams who are specifically working on this, even also education, but
even also testing from the very beginning, even already educating concept and designers
and all of these colleagues.
But in the end, I think it's, yeah, it's about skill set awareness and all of this stuff,
education, talking to each other, all of that stuff.
This is what I could tell you for the moment.
But we could follow up.
Okay.
Yeah.
We are still here.
If you do have anything else to follow up, just come to us, please.
Thank you.