Building (less in-) accessible web sites
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 275 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/51952 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Inclusion mapEvolutionarily stable strategyWebsiteContrast (vision)Computer-generated imageryBuildingLevel (video gaming)CausalityQuicksortDrop (liquid)Multiplication signBitPoint (geometry)Form (programming)UsabilityWebsiteComputer virusDigital photographyRule of inferenceComputer clusterMultiplicationSpeech synthesisType theoryMereologyObject (grammar)Data storage deviceUniform resource locatorSelf-organizationOrder (biology)Medical imagingDifferent (Kate Ryan album)Inheritance (object-oriented programming)TouchscreenComputer animationMeeting/Interview
05:50
Boss CorporationFaktorenanalyseWordRule of inferenceSoftware testingClient (computing)Structural loadServer (computing)Web pageReduction of orderZoom lensScripting languageJava appletCross-site scriptingTemplate (C++)ImplementationComputer-generated imageryAttribute grammarMeta elementLink (knot theory)WebsiteoutputContent (media)Computer fontInformationOffice suiteProcess (computing)Set (mathematics)GradientMathematicsArmSource codeAreaWebsiteCellular automatonMedical imagingMobile WebOrbitObservational studyBitMarginal distributionOrder (biology)Incidence algebraDigital electronicsComputer hardwareBuildingWordHypermediaRankingFormal languageGroup actionSound effectArithmetic meanData storage deviceNormal (geometry)Speech synthesisHacker (term)Internet forumUsabilityRule of inferenceContent (media)Server (computing)TouchscreenoutputSoftware testingPlug-in (computing)Free variables and bound variablesClient (computing)Structural loadCartesian coordinate systemWeb pageInternetworkingGraph coloringPoint (geometry)Projective planeBlogTemplate (C++)Search engine (computing)MehrplatzsystemMaschinelle ÜbersetzungMathematical optimizationLink (knot theory)Computer iconPixelPerfect groupCurveTraffic reportingStandard deviationAttribute grammarLattice (order)Interactive televisionComputer fontSpacetimeSemantics (computer science)Zoom lensGoodness of fitBoss CorporationComputer animation
14:45
Web pageContent (media)Computer fontInformationSoftware testingComputer iconWeb browserShift operatorTouchscreenStandard deviationFrequencyLink (knot theory)Maß <Mathematik>Pressure volume diagramFocus (optics)PixelLine (geometry)Computer fontComputer iconBookmark (World Wide Web)Rule of inferenceWebsiteFrequencyTwitterDifferent (Kate Ryan album)Link (knot theory)BitTouchscreenGraph coloringFlash memoryWeb browserArithmetic meanGeneric programmingContrast (vision)VolumenvisualisierungFamilyReading (process)Lattice (order)Web pageMultiplication signStorage area networkDivisorGoodness of fitSet (mathematics)Point (geometry)InternetworkingElement (mathematics)Maxima and minimaNetwork topologyStandard deviationCodeKey (cryptography)RectangleOnline helpEmailSeries (mathematics)Projective planeNumberForcing (mathematics)ArmStreaming mediaPotenz <Mathematik>Line (geometry)HypermediaState of matterHydraulic jumpMereologyEvent horizonSign (mathematics)Cellular automatonLimit (category theory)Focus (optics)RootFlow separationSelf-organizationRow (database)CausalityStudent's t-testComputer animation
23:41
Link (knot theory)Maß <Mathematik>Pressure volume diagramFocus (optics)PixelLine (geometry)Standard deviationNeighbourhood (graph theory)Cross-site scriptingFunction (mathematics)TouchscreenWeb pageCodeContent (media)GoogolWeb browserElectronic visual displaySource codePrice indexDisk read-and-write headWeb pageExecution unitNumberWebsiteNavigationContent (media)Different (Kate Ryan album)Element (mathematics)Generic programmingVisualization (computer graphics)HTTP cookieTouchscreenBlogLine (geometry)UsabilityOrder (biology)Web browserMachine visionSearch engine (computing)BitLink (knot theory)Keyboard shortcutRule of inferencePrice indexPerfect groupSource codePersonal digital assistantPixelDefault (computer science)Electronic mailing listFocus (optics)Network topologyPeer-to-peerCodeMultiplication signMereologySemantics (computer science)Social classAdditionHypermediaScaling (geometry)Arm1 (number)Endliche ModelltheorieSound effectCondition numberOrbitCausalityMathematicsSet (mathematics)WordBlock (periodic table)Field (computer science)Form (programming)QuicksortExtension (kinesiology)Observational studyFigurate numberGroup actionForcing (mathematics)Contrast (vision)GodKey (cryptography)TheoryElectric generatorTerm (mathematics)Process (computing)Boiling pointComputer animation
32:36
Link (knot theory)Price indexContent (media)outputStructural loadWeb browserType theoryRegular graphRange (statistics)EmailAttribute grammarMobile WebClient (computing)Server (computing)Web pageAxiom of choiceTouchscreenDefault (computer science)Computer configurationInverse elementSpacetimeoutputKey (cryptography)Keyboard shortcutWebsiteSemantics (computer science)TouchscreenComputer configurationServer (computing)Form (programming)SpacetimeAttribute grammarWeb browserRange (statistics)Structural loadElectronic mailing listWeb pageMobile WebLatent heatDifferent (Kate Ryan album)Content (media)WindowMathematicsGraph coloringCanonical ensembleAdditionFunctional (mathematics)Arithmetic meanType theoryOpen setBitLink (knot theory)NumberMultiplication signSocial classRevision controlMultiplicationEmailUsabilityDefault (computer science)Projective planeRegulärer Ausdruck <Textverarbeitung>Validity (statistics)Cellular automatonImpulse responseObject (grammar)Source codeAreaArmSuite (music)SurfaceSet (mathematics)Ideal (ethics)FingerprintInstance (computer science)Video gameTerm (mathematics)Forcing (mathematics)Electronic signatureOffice suitePresentation of a groupOperational amplifierGroup actionDemosceneLabour Party (Malta)Computer animation
41:32
Default (computer science)Computer configurationInverse elementSpacetimeTouchscreenAtomic numberGUI widgetIntegral domainElement (mathematics)Interactive televisionSoftwareoutputData typeSoftware frameworkWebsiteScripting languageJava appletFocus (optics)Web browserGoogolExtension (kinesiology)Mathematical analysisWeb pageAddress spaceEmailPlanningFeedbackElement (mathematics)FamilyMoment (mathematics)Digital photographyForm (programming)Exception handlingArmWeb pageAngleWalsh functionFunctional (mathematics)Forcing (mathematics)GoogolGreatest elementSoftware testing1 (number)Sign (mathematics)Electronic mailing listSurfaceCASE <Informatik>DialectAverageInformation securitySound effectView (database)Point (geometry)MereologyResultantLattice (order)PlastikkarteCivil engineeringFacebookSet (mathematics)Condition numberMultiplicationAdditionProjective planeTouchscreenSoftware frameworkLine (geometry)Data storage deviceWebsiteEmailMultiplication signContrast (vision)Address spaceSoftware developerBlogSingle-precision floating-point formatGraph coloringCartesian coordinate systemMultilaterationGame controllerBitFrame problemInteractive televisionIntegrated development environmentSoftwareExtension (kinesiology)Attribute grammarSubsetArtistic renderingFront and back endsMeasurementWeb 2.0System callDefault (computer science)Different (Kate Ryan album)Intrusion detection systemStandard deviationComputer animation
50:28
WebsiteTouchscreenFeedbackError messageBlogSlide ruleSoftware developerEmailTouchscreenOffice suiteFocus (optics)Different (Kate Ryan album)MereologyModal logicBitEmailOverlay-NetzError messageWeb pageSlide ruleWeb 2.0CodecMultiplication signGroup actionAngleProcess (computing)Sheaf (mathematics)Rule of inferencePosition operatorMaxima and minimaContent (media)NumberLink (knot theory)Expert systemFeedbackLine (geometry)Mobile WebSoftware developerMeasurementFreewareSimilarity (geometry)Reading (process)HypermediaBit rateSymbol tableArmSet (mathematics)Virtual machineTwitterCASE <Informatik>Form (programming)Computer fileOrder (biology)Game controllerDenial-of-service attackTriangleHash functionWordSound effectLevel (video gaming)Arithmetic meanComputer animationMeeting/Interview
59:23
Freeware8 (number)Computer animation
Transcript: English(auto-generated)
00:30
Welcome back to the Carl's West stage. I just saw that in my notes that it's in English. I'm very sorry. So on my other screen, I'm already seeing Jennifer and Jennifer is talking today to us
00:42
about building less inaccessible websites. I'm sure many of you, because most of us are probably hackers, are building some form of websites in their spare time or for some organization or whatever. And one point that's often missed or that many people don't really think about
01:00
is that not everyone is able to use your website like you might be able to. And luckily there are many technologies to improve the usability for people that cannot use the websites like we do. So Jennifer is talking to us today
01:21
about what's possible there. And yeah, I will just hand it off to Jennifer now if you might. Yeah, thank you. So yeah, hello. I'm here today in my own apartment, whatever,
01:41
to talk to you about building less inaccessible websites for nostalgia's sake. And because, well, my talk was lacking images, I've got some photos from last year's Congress. They aren't that important. Oh, okay.
02:05
So I've never spoken in front of such a large and simultaneously slow amount of people. So bear with me if I'm a bit too fast or something. I apologize already. I've got these captions on. If I'm not funny,
02:21
at least they might give me a laugh or something. So yeah, what's the motivation?
02:45
So I'm quite sorry. We seem to be having some audio issues in the background. We are fixing them for some reason. The mic just stopped working for us, but Jennifer is fixing it in the background.
03:01
I'm very sorry, we'll just start the talk again once those issues are fixed. But maybe it's now a good time to remind you that, yes, it's a remote Congress. Everything's a little bit different, but there are some rules that might still apply to you. For example, the 621 rule, if you don't know that.
03:22
Really, please keep in mind, six hours of sleep, two meals a day, one shower. That really helps a lot. I know that if you're at home, it's a little bit hard because you're sitting there, no one really cares about how you're looking anyways, but do yourself the favor, keep care of yourselves,
03:41
and also make sure that after the talk, you bring back your empty bottles to the bottle drop point in your location, wherever you might are. And yeah, seems that still we're not getting any audio. Let me quickly see if there's maybe another microphone
04:00
that we can activate instead of the headset. Jennifer, could you please take a look if there's any other microphone maybe, maybe even the built-in one. So we're still frantically trying to fix it,
04:22
but yeah, technical problems everywhere. I mean, this is really amazing that it's even possible to have these talks at all. And I think I'm getting some audio now. So it's a little bit quiet. I'll have to do some adjustments on my side.
04:42
I'll quickly fix that for you. Speak again, please. Yes. Okay, yep. It seems to be that you're audible again, and I'll switch back to the other slides and let you maybe start again from the beginning
05:03
and let's continue. Yes, I apologize for that. I turned off the captions. Maybe there's some issue with multiple types
05:20
using my microphone or something. So I'm sorry about that. So let's try this again. Today I want to talk to you a bit about building less inaccessible websites. I have some not very important things there.
05:44
Sorry, I'm making you talk better apparently. Yeah, so let's get started. What's my motivation for this or what should your motivation be for making your websites less inaccessible? It's a somewhat general rule that I try to apply to most interactions
06:02
and most stuff I do. It's not being there. So, but probably your boss won't be happy to hear that if you've got one. So here's some nicer words.
06:21
If you improve your accessibility, you will obviously be able to have more customers because disabled people use the internet too. And they will also talk about what they are using. So if you're more accessible than your next competitor, that's also a great point.
06:42
And it also helps you a lot if you are less accessible. There's also the curve effect, meaning that your X improvements for people with disabilities will usually help everyone. Not all of them will, but generally speaking, it's just great your X for most people
07:03
who use your site. And also search engine optimization. Google takes care to mostly rank pages that are somewhat accessible highly. And yeah, overall it's comparatively little effort to improve on any of these factors.
07:20
So that may be a reason to get started. What's the scope of this talk? Because accessibility is a huge topic and I obviously can't talk about all of it. What I want to do today is give you some place to start
07:41
if you haven't considered accessibility yet or if you just don't know what to do with your current site. So I will talk a bit about general rules, about where to start and this metaphorical low-hanging fruit. And then I'll also say what you should avoid when you're building new things.
08:04
So yeah, then I'll be talking a bit about semantic HTML, which is something that will help accessibility a lot. And I will just tell you a bit about the basics so that you once again have a point to get started.
08:21
If what you want to communicate can't be communicated using semantics, you may use ARIA. That does not have anything to do with Nazis. It stands for Accessible Rich Internet Applications. And I will show a couple of ARIA tags and tell you what they're for and how to use them.
08:44
Then some nice-to-haves, like questions you can ask yourself if you get to change a lot or if you're starting to open a new project. These are things that can generally be implemented in already existing projects. And at the end, I will give you a bit of an intro
09:02
to how to test the accessibility of the site. So yeah, some general rules. The most important thing is to listen to user plugins. You should not pause specific fonts. You should not pause specific sizes. You should definitely not prevent zooming
09:20
and please don't implement smooth scrolling. Glasses come with smooth scrolling and if people disable it, they disable it because they don't want it for whatever reason, maybe a low-power device, maybe a motion sickness. Please don't implement that yourself. It will also break. Then if you're listening to the things
09:43
that's important to get started by, you should also consider the principle of power. So if you can build something with HTML and CSS, don't use JavaScript for it. That's because accessibility isn't just about visibility.
10:00
It's also about people with like older or slower hardware, bad internet connections and generally JavaScript will perform worse and it will also increase your page size, probably. And once again, internet traffic isn't free so you should decrease your page size.
10:23
And one thing that I think is important is that load on the server side is generally better than load on the client side because if you've got your template that is prepared, you can usually cache it for multiple users and if it's made on the front end,
10:42
you can only cache it once or every user has to compile it at least once. So also we've got these servers that are made for it and you never know what devices your users are having. So if you can move your load to the server side.
11:00
Oh, some more, where to begin if you've already got something. First things first, very easy to check. Do you have a lang attribute on your HTML tag? That will tell screen readers how to pronounce it and give them a couple of other neat improvements
11:20
and it's really no hassle to do. And if you mix languages that you know that you can add a lang attribute not just to the HTML but to any tag. So let's say you're building a social network and people are writing posts in whatever languages, you can theoretically give any post a tag
11:40
with the language that it is written in and screen readers will know how to pronounce it. Then another thing that's quickly to check and to fix is do all of your images have an alt text? Yeah, there are some flat images that don't need one but you need those images because they will also increase your page footprint
12:01
and you should consider what you're reading with them. Also, if you're localizing your site and you're localizing the alt text because I've seen sites that don't and it's kind of a shame because it's really not that much of an additional hassle. Another thing, do all inputs have an associated label?
12:22
This serves multiple purposes. A screen reader will know what to tell someone when they're activating some input so they will know what they have to enter. And also if you click on a label usually the input will be activated. That means people who have issue clicking
12:41
on small text or whatever, or if they're on mobile and such is always a bit more difficult. They've got a larger space that they can interact with. And generally it's also not too difficult because usually you will already have some text
13:03
saying what people should input. And if that text is the placeholder you should also reconsider that because face orders will often not be translated by website translation to it. So that might break some usability for some people.
13:24
And the label is just better because maybe someone entered something and then the face order goes away and they forget what they're doing because they've got a shorter attention spanner, any other number of issues. Do we have a major report tag? And if you've got one, is it a good one?
13:41
I've got this very basic one on the slide. You can use the major report tag to prevent the zooming and to salvage your beautiful pixel perfect design however you should not do that. People change those settings for a reason.
14:02
And the last thing, do all links and buttons contain useful text? So if it's just an icon, a bit difficult if you can't read. Well, if you can read that, you can't see the icon for whatever reason. So links and buttons should contain that. That actually says what they do.
14:22
Some more things that you could ask yourself with your existing project is what color contrasts are within the main page content. So like your blog posts or whatever. There are automatic testing tools that can tell you where you are missing the mark. And generally there's a standard WCAG AA,
14:45
which you should strive for meeting. AAA is also good, but it severely limits what colors you can use. So AA generally is a good midway point. Really use color alone to convey information
15:02
because if you don't, don't. There are many reasons why people will not be able to see that color and if something is important, just tell them this is important or this is wrong. Don't just color something for people.
15:21
What fonts are you using is another thing because sans fonts are generally more accessible. Serif fonts may merge into one another and just are more difficult to do. And another thing considering fonts is
15:41
do you really need to download external fonts or can you just use some generic font family that people already will have? Because having to download a font costs a bit of data and also it may fail and the site may not look the way you want or maybe it's slow and you get a flash of un-stayed text
16:04
and probably even layout shifting, which is pretty bad if you're trying to read something and then what you're reading somewhere else. Another thing that's quick to implement is jump to content and jump up button. The skip to content button usually is some invisible link
16:24
as the very first element on your site that will only become visible once it's focused and it will allow people to skip the navigation to just get to the juicy bits. It's not strictly necessary and I will tell you a bit more about why
16:41
and what you can do instead, but it's nice to have in very little effort, just a tiny bit of CSS to hide something that's not focused. Yeah. So you did all that, you got it started, now you're really motivated to do better in the future
17:03
and avoid new pitfalls. What are those pitfalls? This is like, the first one is like a personal favorite of me, it's icon fonts because we see this on one of the Google Calendar header here,
17:23
got some search and help and settings, icons, and this happens when I force a font. I can't tell what those icons used to mean. It's interesting that two of these icons still work and this is definitely not the worst example
17:42
of this series. So it's actually rather common that websites are not usable because icons just don't work on the font number font. Also, icon fonts aren't screen reader accessible because what should the screen reader pronounce here?
18:02
It's usually some very high character code that just doesn't have an associated pronunciation and you should definitely hide them to prevent screen readers from saying stuff that you don't want them to. So that's the ARIA hidden tree tag format.
18:21
They often cause a flash of unstay text once again and layout shifting, especially if you've got a large set of icons that have to be downloaded. Obviously, they can be cached, but that's better to not include them. Also, these days, if you don't have to
18:40
support all Internet Explorer, which also is an accessibility thing because yes, some people are forced to use all Internet Explorer, but if you're thinking about that, generally having to support these old browsers will hurt everyone who's already knew about it because it's just most of the time not worth it.
19:05
So yeah, most browsers these days can display inline SVG, so you can just use SVG icons and if you're not going for a serious look, how about emoji? Because screen readers will know how to pronounce emoji
19:22
and they are already on most systems, so you won't have to fight for this. Also, you've got your cool inline SVG icons included and you're really happy, but you should still not use them to convey meaning alone because actual differences or whatever may mean
19:42
that someone doesn't understand what this icon is trying to tell them or maybe they don't render for whatever reason. Generally, it's just a good idea to also add explanatory text. If your layout doesn't allow it because you've got to have this very small search button
20:02
or whatever, at least add an explanation text that is only visible to screen readers. It's also a rather small CSS rule to add that. So that this text will not be seen but pronounced. Yeah, what more to avoid?
20:23
You fix your contrast, you're really happy, but now you've got black text on a white background or pure black text on a pure white background. That can cause issues as well because especially when you have to stare at it for a long time, it will cause slight visual hallucinations
20:42
or some bit of movement, maybe flickering, especially for this lexic users. Using just slightly gray tones instead will fix that and it won't actually be too obvious. So it probably will look the same, but you've still got this added accessibility
21:03
while still being able to meet AAA standards if that's what you're striving for. Yeah, once more layout repos, they are caused by more than just of un-styled text and they should definitely be avoided. As I just said, if you're reading something
21:22
and then sending it somewhere else, that is bad for everyone. Excessive motion, does your website really need motion at all? And if it does, you should listen to the browser tag that tells you if users prefer to not see it
21:40
because there is a setting that people can set and if they have got motion sickness issues, they will, if they know about it, they will set it and yeah, you can listen to these people. Also blinking, something that generally serves little purpose
22:01
and makes it harder for people with photosensitive epilepsy, from what I've read in preparation to this talk, flashing at 15 to 25 hertz will trigger seizures in most people with photosensitive epilepsy. So if you've got to have flashing, it's a good rule to stay below a frequency of 15 hertz.
22:24
However, other flashing frequencies can still trigger seizures, although less likely and there's a lot of small factors like what color you're using, how long is the flashing shown, how large is it. So generally, it's easiest to just avoid blinking at all.
22:43
Even more stuff to avoid. Removing the underlying from links. That's a trend that somehow people use because they want their text to look uniform but those things are underlined for a reason because people want to know that something is interactive.
23:02
They will want to know that it will take them to a different page and if it's underlined, they were used to this being a link so they know what to expect. If you really have to remove the underlying, at least color them differently. There is a WCAG standard for the minimum contrast
23:22
between link color and text color, so you should need that so links stand out at least. Also now the thing you are using, imagine you're showing people your amazing cool new project and then someone hits the tab key and now there's some ugly blue rectangle
23:41
in your page and you don't want that because you spent so much time on the design so you're just adding CSS to remove that focus indicator so your design is so rich but don't. It's there for a reason. It's there to tell keyboard users what they are currently interacting with and you can also style it differently
24:02
but I would just leave it as is because people maybe have their own browser styles so that it always looks the way they expect it to. Yeah, just leave the focus indicator as is. It won't hurt the design that much.
24:21
Generally relying on this pixel perfect design or whatever, it's not a good idea because it will break even without assistive technologies but with assistive technologies it will definitely break. You will never know what kind of browsers people are using, how their sites are rendered or anything so you just shouldn't rely on that design
24:42
because a broad design can mean that your otherwise good contrast isn't good anymore because why text is overflowing on a wide background or anything. It's not a good idea. Long lines of text are another thing that are difficult for people with dyslexia
25:03
or short attention spans, short attention spans. So it's a good rule to just limit your lines to 75 characters. I've got a little CSS thingy there for how you can do it
25:23
and this will mean that your text will be more legible to people with dyslexia. Another thing, long uninterrupted paragraphs are difficult to do for most people but if you've got dyslexia or ADHD or any other of a number of other disabilities,
25:45
it will just make your site unusable. And absolute units generally should be avoided because people can set the default text size and if you set your text size as percentages, it will scale with what they have set
26:04
as a default, which generally is good if you have low vision and you have got your browser set up to have really large text. Okay, so now a bit more to avoid. We know that we have to start checking out our website
26:21
and what we can do. So let's talk a bit about the basics of semantic HTML. Only the very basics, although it isn't a difficult topic, it's not in the scope of this talk. So I will just show that and yeah. So yeah, let's look at this generic startup website
26:43
that I've got here as an example. We've got a small navigation, then we've got our main content, a large cookie warning and a photo. Obviously, visual pages look different because they've also got content and head and body,
27:03
but this is just a small snippet to illustrate it. This is the site that will look identical. You will see the color in text. Here, we only have different span. Here, we've got a large number of different text
27:22
that all means something. We've got our nav tag as a container for the navigation, then the links are in an ordered list, then we've got the main tag for page content. We've got an article, which doesn't just mean
27:40
like a blog post or anything, but an article is anything that can stand on its own. So anything with kind of like a heading and text or something. So a blog or a post on social media and then an article too, for example. We've got our H1 as a start, and then we've got an H2 within the article.
28:00
It's important that those H numbers actually count down, and there should only be one H1 because yes, they change the size, but that's not their main purpose. Their main purpose is to be adding and you can change the size in CSS.
28:22
So just use those responsibly. Then we've got a footer. And yeah, why you should use the H1 and so on responsibly is because
28:41
there's a thing called the accessibility tree, which is a list of all the main parts of your site that people can just see and decide where to jump to. So especially if they're using a screen reader, it will be really annoying if every single page
29:00
will have the navigation that they want to read from article, yeah. So let's compare the two snippets. We've got a bit less lines of HTML, but those lines are longer because everything's got class names in that snippet. But also in addition to having longer lines,
29:22
you will also need CSS to just make sure a heading looks like a heading, a list looks like a list or whatever. And JavaScript is necessary just to click on the navigation. All of that isn't even an issue with the somewhat semantic snippet,
29:40
which also definitely is not perfect. Yeah, as I said, without the accessibility tree that comes with using those page layout tags, screen readers will have to read all of the page and all the code is difficult to read, in my opinion. Well, that's not good.
30:01
So there's accessibility for your peers who may have to also work on the website. And also, the best snippet will rank rather low on search engines and Google Access if you're somewhat symmetric or the more the better.
30:23
So the page layout tags, which you've just seen, are like the easiest to implement because generally you will just have to change divs and spans to more useful tags. Those usually don't come with default styles,
30:42
so it won't actually change your site too much to use those tags. As I said, screen readers can jump between those tags. And there's also special browsers that just don't run on them. And these browsers will rely on article tags, for example, to know what to show.
31:03
Just as I said a minute ago, you never know what browsers people will be doing. And generally, yeah, it doesn't add much complexity to your source code. Then links. HTML provides links and buttons. Many people don't seem to know this these days
31:22
because they build their own and they fail spectacularly. Common reasons for failing are only setting on click handles. Of course, that means links won't be usable with the keyboard or maybe they are usable with the keyboard in theory, but you can focus them with a tab
31:42
because they don't have a tab index, then it's usually not terrible. Or it's got a tab index, but it's a wrong one so that the visual order of elements isn't the tab order, which is something you should definitely avoid. Also, another thing that I've come across
32:01
is forgetting to add handles to lazy-loaded content. So I've got a site that works rather well. I can navigate using my keyboard, but then some more content gets loaded and suddenly all the links can be opened and clicked on them because for some reason it was just forgotten
32:21
and no one bothered to check if this still works. Then the links and buttons work quickly, they perform well, and they work without JavaScript, so they're good. And they also work as expected if the user may have set different interaction keys.
32:41
So maybe they've got issues hitting the enter key, so they have got something set to it, and you generally only listen to the key code, which won't be changed, users will not be able to interact with the key. Generally, considering links and buttons,
33:00
use what the spec gives you. Maybe if you really needed, add some more JavaScript functionality afterwards, but you usually don't need to do that. Inputs, HTML, and especially HTML5, contains lots of different input types,
33:20
and these are just a few that I have used in practice and that I really like, which is color, which I use as a color picker. Date, obviously, and email,
33:40
which I think is really useful because of two reasons. Mobile keyboard will replace the return key with an add key, usually, and the input type is an email, so people don't have to search for that. And if you've got an actual HTML form, it will not be able to be submitted if the email is wrong.
34:02
And that regex generally is a pain to write. You still got to check the emails on the server side, obviously, but yeah, I usually just look at this and add emails, if it is, it will probably be okay, and yeah, if it isn't,
34:21
they won't be able to use the URL or whatever, so it's not that good, I'm not sure. So there's tons of really useful input types, and you can check caniuse.com, which is the site I really like, to just see if a specific input type is available on all the browsers that you have to support.
34:42
And a bit of a personal key, don't use the range input type. If we give you a slider to input numbers, it's not very usable, it's not very accessible. It's a pain to have some specific number that you want to select,
35:01
and a simple number with lowest and highest available values will work just fine, and probably also a good version. Range is also a pain to style using CSS because every browser's got their own way to show it, and let's just not go there and know that input type exists.
35:26
Yeah, browser support is good these days, unless you have to support all the IE, you usually don't have to worry about it too much, and these are usually just preferable to bring your own because if you want a date,
35:40
you may have to open some, use JavaScript to open a window where people can click on a canon and then you have to write yourself or use some jQuery UI, that's what usually people have for this, which doesn't perform too well and doesn't really work on mobile,
36:00
and also it's not what users are accustomed to because the more sites use the HTML inputs, the more people will know them and know what to expect when a specific kind of keyboard pops up or a pop-up or whatever, looked the way they wanted to, or their browser manufacturers wanted to,
36:21
so yeah, it will generally be better, and you also don't have to worry about making those accessible because if it isn't, if the browser has implemented it in a bad way, that's generally, people can use a different browser to browse your site, but they can't use a different site to browse your site,
36:42
so yeah, obviously. Yeah, and as I just said, a form can be submitted with an embedded value entered, still do server-side validation because anyone can still push whatever data they want, but it will just be a bit of usability
37:01
if someone entered a comma instead of a dot at the end of the email, as I would be told, you will save a round trip to your server and JavaScript code. So there's loads more of semantic HTML stuff to talk about, but I will leave it at this
37:21
and move over to ARIA. So that's a bit polemic in the first sentence here. They are not really for when, they kind of are for when semantic HTML fails you. Reasons for that include the inability to change tags in legacy projects.
37:42
You can't just change something to a header because we will never know what other things it will change. Interactively changing page content is just something that HTML wasn't made for. Also, design choices, you don't get a say in multiple inputs
38:02
of the same label if you're working with other people and those people get to decide that stuff. You can still save some accessibility using ARIA tag. Backwards compatibility to HTML4, meaning a bit more old browsers will be able to use your site if you've got to support them.
38:23
And yeah, it's also usually a bit quicker to save some accessibility using those tags rather than rewriting HTML. So the first ARIA thing to talk about is an attribute that doesn't actually start with ARIA.
38:42
It's the role. There are loads of roles. Just check out the MDN page for that. And MDN, yeah, sorry. Okay, roles were mostly introduced
39:01
before HTML5 semantic tags have been used. So if you don't have to support browsers or using a semantic tag, it's still preferred. However, roles also change the default values for other ARIA attributes, for example. So something that doesn't have a semantic tag as fast
39:21
and I was looking at that. So the role alert will set the value of ARIA live, which is something I'll talk about in just a minute, to assert it. So that's a bit of a class that you should also predominantly also add that role, just to be sure,
39:41
because you never know, maybe the role is implemented differently. Yeah, I've got a role here for some alerts that hopefully will not pop up. And yeah, just to add accessibility without risking layout changes, I once had a site I maintained where the,
40:06
I thought that one tag was used for headings, tag that was just not actually available where it was used. So I changed it to a spam with a role heading because I just didn't have time to do all those things
40:21
that I should make sure the site doesn't get. Then, in my opinion, the most important feature of ARIA live regions. ARIA live is used to tell screen readers
40:40
when to announce changes to the site content. Options are assertive, polite, and off. Assertive means that the screen reader will stop whatever it is saying to announce any changes to the content. So it's like a really important thing that you need to use it to know.
41:00
Polite means it will finish what it's saying and then jump to whatever has changed, and off, which is really fun if you don't set it, will just not announce any changes. Just like in personal conversations, usually it's just best to try to be polite. ARIA relevant, in addition to ARIA live,
41:23
is used to tell screen readers what to announce. So the options are additions, removals, tags, and all, which can also be combined here in the space of the list. So additions means every time something is added to your live region, it will announce removals,
41:42
obviously, you'll have those. Tags means if any tags within your live region will be changed, that will be announced. All is equivalent to all, and the default is that additions and tags will be announced. So you don't always have to set this
42:03
if that's what you want. ARIA atomic is very useful, but it's good to know about. It tells the screen reader whether or not the whole region of something changes, which could get annoying with a large container
42:22
that contains lots of text, and only a little line at the end is added. Default value is false. In general, you want to keep it as false, but still, it's there often. ARIA controls is used to associate an interactive element with live regions.
42:41
It isn't too well supported in screen readers because it supports a space-activated list of IDs for multiple live regions controlled by the same control, but if you think about it, what should the screen reader do in this case? It can only say one thing at a time. So yeah, the software support is low.
43:03
I've got a very angry blog post saying that this attribute is shit and should definitely not be used. I disagree a bit because putting it in there won't hurt accessibility, usually. Yeah, it's not true, it doesn't add any complexity.
43:27
I've got some simplified example here because these live regions are difficult. Obviously, the site would not work the way it is, but yeah, I want to show it just a bit.
43:42
We've got some search box, and I've realized a mistake. The ARIA controls should be on the button or not on the input, I'm sorry for that. So yeah, we've got a search thing. People can enter what they want to find,
44:01
and then we've got the search results, and inside the search results, there is a live region, and this live region is polite, so when I hit the button, an AJAX call will usually just fetch the results. Once it's done, screen reader will probably announce it
44:24
unless it's currently saying something else. Everything is relevant, so yeah, if for some reason you search something and the results are less, but a subset of what was previously there will tell you.
44:43
Yeah, so it's basically just of those live regions. Some nice-to-haves when you can change a lot or questions you should ask yourself. Copy designs generally or often include low contrasts.
45:05
If you get a change, then maybe you could because it's not as important as the page content, but it's still a good thing to have a high contrast of new project design. Do you really need that fundamental framework
45:22
that you just read about some cool hacken news article about because those usually aren't too accessible, and they also often have a client-side rendering which I don't like, which has accessibility,
45:44
and yeah, maybe you can just do it with another JS. It will be quicker, and yeah, it probably doesn't not look as good on your CV, but that's about the only downside.
46:01
As following the latest front-end design trend, really bad and important to you. A couple of years back, I recited Parallax, which looks cool in my opinion. It looks so cool that whenever I encounter it, I spend a couple of minutes fiddling with the zooming, then I forget why I visited the page and close it up. Not too great.
46:21
Maybe just having somewhat plain sight is better for your users and you because you don't have to implement some great new thing that you will have to remove in a couple of minutes because it's out. Then another thing, can you make your site work without a pocket frame in JavaScript? Not always possible.
46:42
Like if you're making a single page application obviously, making that work without JavaScript would be difficult, but if you can, do it, and then add on functionality using JavaScript later. So the site should be usable, but maybe some fancy things will still happen
47:02
when people have access to it. And if this applies to you, maybe ask yourself if your dev team should probably be a bit more diverse because a more diverse background in your developers will mean they will find more issues and that is a better result for everyone.
47:26
Next, how do I test? This is obviously, once again, not everything you can do with it. A quick way to start tabbing through your website and using the website just without touching your mouth is a good start because if you can reach every element,
47:44
if you can do everything that your website does, it's a good sign that your website will work rather well with assistive technologies. Using a Chromium-based browser, you can run Google Lighthouse, which will give you lots of audits, including many accessibility audits.
48:04
Meeting 100% in Lighthouse does not mean your site is accessible. It just means your site is not as inaccessible as it would be if it didn't. You will still have to do other testing, but it's still, in my opinion, a very good tool. And you can also include it in the CI workflow
48:22
so that pull requests can't be merged if they would use the accessibility store or something. Checking the contrast for all elements, especially, once again, the main content, is a good thing. Firefox has an accessibility inspector that works really well for this. You can hover over every element in CD contrast ratio
48:41
and what standard it does or doesn't need. I really like that. And there are also web extensions that simulate different kinds of color blenders. Trying them out can be really, really interesting to just see if your site is usable to people with those kinds of color blenders.
49:04
Then you did a bit of testing. Now it's time to ask your users to test, but only if they're neutral, obviously. You can add, and just like with security, you can add an accessibility page to your website, write down every measure you've taken to improve accessibility,
49:21
admit to known issues, and what you are doing to fix them, which also gains you a bit more trust and will make people more likely to actually submit any issues they have found because they know you care. Provide an accessibility email address
49:42
and actually read it and fix the issues that people send you. Also, provide some kind of reward. You can maybe just ask them if they want you to add names, written somewhere in credits or whatever, or a monetary compensation if you're able to give it, it's always good.
50:03
So the last things that you can do are more applicable to a corporate environment or to side projects that you take the time to do. Lots of time. Because never getting inside of the screen here takes time if you have to learn that.
50:22
Well, it's also extremely valuable to be able to. Mac OS is voice-over integrated and it's rather easy to use. It only takes a few button presses. I'm not too biased towards this, however. There are definitely other screen readers for free or paid. However, some of them may be a bit more difficult to use.
50:42
So I tried using Orkra once and I couldn't get it to work with Firefox and there seem to be a bit of some issues. If you're using a Mac, many content developers are just trying out voice-over once on every couple of versions, maybe a good idea.
51:03
And if you can afford it, pay disabled people to do QA for you. Obviously get you the most valuable feedback because if they're in some position where their job is to do QA, they will find more than people who just are doing
51:24
what they personally want to do on your website. However, different disabilities still require different accommodations. A single person will never be able to print everything. And if you're a blind user, says this page is amazing, but the dyslexic user can't use it,
51:42
that's not too bad. So yeah, but a little bit if you can afford it. Some last remarks. I'm obviously far from perfect. There could and will be errors in this talk.
52:01
I will be publishing slides in the short meta-block write-up of this talk on my blog, which is at strike.dev. And if you've got any questions, you can, can't be asked during the QA part. You can email me at RCfreetalk at strike.dev.
52:22
Just note that my RSPMB is set up to drop any emails containing the phrase, this is more of a comment. Yeah, and if you're a professional web developer, joining a union or starting a workers' council can also give you a better position to talk with your employer
52:42
about accessibility measures in my phone to implement. So that's it for now. And yeah, my timing is not perfect, but yeah, we have lots of time for questions.
53:02
Thank you. Yes, thank you. Thank you for the very interesting talk. You're right, we are now in the Q&A section. So our signal angle has been very,
53:23
very hard at work to gather all the questions that you have posted. If you have any questions now, please put them now either into the IOC channel, hashtag RCfreet-cwtv on the Hacken network,
53:42
or use the hashtag RCfreet-cwtv, now without a dash, on any Twitter or Mustardan account you have, and our signal engine will hopefully pick them up. I'm very sorry about the microphone quality. You might have noticed that it's not up
54:00
to what we wanted to have. Sadly, there was a technical issue at the end, and thanks to Jennifer for quickly fixing this. It was sadly the best that we could come up with on a short notice. I guess if people didn't understand the section, but wanted to learn more, they could probably also send you an email,
54:22
is that right? Yeah, a whole year I've worked in home office and now my headset stops working. Yeah, that's a little bit bad, but sadly that's the situation that we have now with this whole pandemic thing going on, but what will you do?
54:43
So some questions have already been prepared, so thank you to our signal engine. One very interesting question, how do screen readers handle modal overlays or similar features? Depends on how you make them.
55:04
So a modal would generally be a live feature that would probably also get the ARIA live assertive because if a modal pops up, it usually takes the focus away from whatever
55:21
someone's already reading. So you would add this ARIA live. Yeah, perfect, that's very interesting. And one, you did talk about buttons and using semantic HTML wherever possible.
55:42
And there's one question about useful text on links and buttons. Is there any reasonable number of maximum characters on buttons or any other best practices there? I don't know any, to be honest, but yeah, if you've got a button that's 70 characters long
56:04
or 75, like the line of characters that I talked about, that's probably too much. Yeah, or the lowest amount of characters, there's actually an audit on Lighthouse for that.
56:26
So it's not about the amount of characters, it's about the size of the button so that it is clickable, even on mobile. So that will tell you about such a small. Okay, so go to Google Lighthouse
56:41
and see if Lighthouse screams at you, then you're probably doing it wrong. Not a guarantee, like you said, that is correct, but at least you know you're not especially wrong there. Okay, and one more question that I'll have to parse this a little bit.
57:01
So one of the thing about accessibility seems to be that experts on web technology are much more preoccupied with themselves rather than like fixing the actual issue. So there's this question like this holy, there can only be one H1 tag in a page.
57:24
How do you think this relates in respect to accessibility and what should a user of web technology in this case take from such like maybe elitist views and do you know if there's a middle ground or something that they can stick to?
57:46
The thing with the H1 tag is that it's mostly because H1 just means that this is like a general heading for the entire page. So there may be a discuss where you've got to
58:04
have multiple and don't believe that any groups should always be followed without thinking about them. And all of these are just things that you should consider that this is not a bible and we're not fundamentalists.
58:24
So it's really forgetting feedback people saying that everything is good or bad and that's definitely more important than following rules. I hope this answers the question.
58:42
So in essence again, put in your head and try to see if what you're doing makes sense and actually works on screen readers. This is probably the best advice or no hard rule to follow. Okay, cool. I think those are all the questions that our signal angel did collect.
59:03
So it was a rather short Q&A but you did show us a lot of details and a lot of interesting things about Aria. I did learn something myself. So hopefully all the other people watching learn something as well. And yeah, I want to thank you for your great talk.
59:22
Yeah, thank you for your time.