[Applause] PATRIK: Ok, before we talk about continuous
accessibility and automation of accessibility, we should take a look what is accessibility?
Accessibility for short if you read that as a11y, for pronounced "aly".
What is accessibility?
It is simple: make your website accessible for users with assistive technologies, like
a screenreader, or people who need a magnifying lens or people who are not capable of using
the mouse, and depend only to have it through your website.
But also maybe websites accessible for users with other disabilities.
Imagine a form, and the error on this form.
If this error is only with a red border on the input, is it accessible?
No, it is not, because if you have users who are colour blind, they can't see a difference
on this form.
Because the red border is not visible for them.
But it is also to make your website accessible for search engines.
If your website is not accessible for search engines, it wound be found and your stakeholders
will be angry.
Of course make your website accessible for legal reasons.
As an example, in Austria, we're not allowed to discriminate based on disabilities, even
on the web.
We have a law for that.
So it is like a little code of conduct in our laws.
That's nice.
So, please make your websites accessible.
There are different conformance levels.
First, we have the web content accessibility guidelines of the W3C group.
There are three different levels - A, AA, AAA.
For America, you have the US Section 508 legislation, and for search engines, you need to follow
the HTML5 recommendations.
How do you test?
Show your hands who does accessibility testing already?
Not that many, but a few.
Do you test manually?
Who is already using automation tools?
One, two, three ... okay.
Nice.
So.
Let's enter automation.
My day-to-day job at Pixelart is - so automate all the things!
Yes.
But we should compare our manual testing steps with automated testing steps.
Manual testing is of course slower and automation is faster, but on the downside, automation
can be accurate, depends on errors and testing standards.
You may miss pages or links.
Manual testing can be completely accurate.
You can get false positive information - maybe, maybe not.
And on manual testing, it is easier to miss a link.
You miss your imprint, maybe not that bad, maybe bad.
It depends on your legal, on your law.
And with automated testing, you have a guaranteed check of all links as long as all your pages
are crawlable.
It is easy to find content which depends on user input, like a complex form or complex
check-out step, and an automated content can be missed when automated user input is used
which means you have user input for a complex form which tackles only one case and another
case because it is a multistep form.
So, automation is not the force.
You should compliment your manual testing with automation testing.
Repeat with me.
I will not skip manual testing in the favour of automation only!
[Laughter] Before please repeat with me!
"I will not skip manual testing in favour of automation only!".
Thank you.
That's not only for accessibility testing but all automation tests.
So combine them.
Complement automated testing with manual testing only.
But what should we use?
Let me introduce you to the accessibility Metropolitan called a11ym.
It is short quick enough to remember that.
What is a11ym.
It is a testing tool that crawls and tests pages of any web application to produce detailed
reports.
That's the official description on the GitHub repo.
The prosecution are you can run it locally and run it on your CI server.
You can test every patch, reduce the test loop, and, of course, you can test your private
code.
It is not restricted to open-source code or publicly available code on the web.
You can test your code in private behind your firewall.
You're not depending on any software for service product.
And of course, you can test authentication-required parts.
You can have a step behind the log-in?
You can test it too.
You can crawl all your pages.
Of course, it behaves like a crawler.
If you recap that: it runs locally, you can test private code, - privacy.
You may not think it is good for you.
Put it on the test and test it.
If you're a big corporate, you need to mind the privacy of your code.
It may be has patents pending or it should still be behind a firewall.
That's the best part of a11ym, it can test your code.
At this technical - why not have a second tech talk?
These slides are for your team leaders to give them to your team.
Let's take a little look at the usage of this tool.
You call it a11 wrom with an output to an URL and crawling.
A simple tool, easy to use.
You have some errors, warnings, and we have many notices on this page.
Notices are not that bad.
It depends on your page, on your cast.
Of course, you have you have many URLs down there.
If you look in one specific report like start page, you have still a cake with eight errors.
It is okay.
Eight errors are not that much.
Still many notices, and your detailed error report like image element with an empty alt
text must have an absent or empty title attribute.
That is conformance level A, principle 1, and so on.
You see S selector to find your error node element and of course an extract of your code.
This could be now a coding error, but this could also be a data error like the editor
of the CMS has written the title attribute and you but not a - attribute.
That may be wrong.
Maybe the devs had done the error because they are only outputting the title.
You have to inspect that.
That's nice, but still with every tool, you want to rely your devs on putting these parameters
every time they need to use it, so user config file, use the URLs, define the standards you
want to use in this example.
Double - combined with recommendations.
Your devs only have to use that, a11ym with a bootstrap of the a11ym.yaml file.
That's all.
You get the same report, and you get the same errors.
Of course, if you want to try to test in higher level, use other parameters, all the command-line
parameters overwrite the configure line pram fares.
This is not automated yesterday.
So, let's automate all the things.
Our scenario today is we're using on a CI Server Jenkins, GitLab - you should use an
NCI server, please.
Test on everyone branch.
You want to test everyone feature and bug fix.
You're using cleaned production data.
Don't get a copy of your data without clearing out names, user names, and so on, should not
land on your CI server.
Our accessibility pushed to AWS S3.
Simple.
This is a simple script you can give to your developers.
We are syncing down to the old reports, the CI server, and now generate a new report.
Minimise, that's not mine.
It doesn't matter.
We are generating the new report.
Now clean old dashboard and clean old reports the eight newest.
Now we generate a new dashboard and sync it back to 3.
A simple build script, put it in your CI server.
That's the a11ym machine dashboard.
You get a timeline of the last eight new reports, the reports down there, with a date, time,
UTC, the only valid time zone, and a commit - comment hash.
You want to know which comments they have they have tested.
You can exit the dashboard or push it to any other web server host you have and that's
all.
You can inspect all errors, great new bug reports, and so on.
What is next?
For you who don't want to use the locally watch, a11ym.com because the software service
with a tool, Liip AG from Swiss, and we're creating a Jenkins plug-in for that because
year tired of pushing because we need to maintain the link, a list of links, redistribute them,
so a Jenkins plugin which runs would you please tell the script, an integrated dashboard,
so you see how your build evolved.
Integrated reports on every build.
Or/un healthy thresholds, because if you remember the dashboard, it was okay, but if you have
sudden ly 20, 50 new errors, it is not okay.
The build should fail, it should not deploy.
If you have five new errors, the build could be marked unhealthy.
In Jenkins, you have three states: failed, - unhealthy.
Creates JIRA bugs on new errors.
Error you get in the report, it gets a JIRA ticket.
With this Jenkins plugin and a11ym together, it is now continuous accessibility.
And that's awesome, to be true.
So, yes.
If you have a question about a11ym, about Jenkins plugin, simply call me on Twitter,
or write me an email.
That's all.
Thank you.
[Applause].
MERI: I was hoping that there was some amazing Austrian kilt tradition that I'm not aware
of.
I'm not from around here.
PATRIK: It's more Health Head tradition!
MERI: I see!
Awesome.