Conversations about Software Engineering

Conversations about Software Engineering (CaSE) is an interview podcast for software developers and architects about Software Engineering and related topics. We release a new episode every three weeks.

Transcript

00:00:15: Welcome listeners to a new episode of the CaSE Podcast. Today we will have a conversation about software engineering for the topic "Responsible web applications." To do that, I've invited Joy Heron. Hi, Joy.

00:00:27: Hi.

00:00:29: Joy is a senior consultant at INNOQ. She's also well-known for her contributions to the CaSE Podcast, the very podcast you're listening to right now. She's a full-stack developer and she has a lot of thoughts about good frontend development and good frontend principles. That will be our topic for today.

00:00:29: Before we get into that, we probably need to talk about the word "responsible web applications", because it sounds like I've mispronounced something maybe, but I have not... So can you explain what responsible web applications are, and what it means?

00:01:06: Yes. It actually comes from a mistake that I made... So if you feel like you accidentally said something incorrectly, it's not completely wrong. The term actually came from when I was trying to say -- internally, I wanted to show some colleagues some tips and tricks that I have picked up over the years for writing applications which are responsive and accessible. And when you say "responsible and accessible" -- I just did it right now. When you say "responsive and accessible" too long and too fast, it comes out "responsible".

00:01:43: And so it was kind of a mistake when I said it the first time, but I think it works, actually... Because I feel like we as web developers do have a responsibility to make sure that our applications work on every device (that's what responsive web applications means), and for every user, which is what accessible applications means. So the word "responsible" - I think it actually really works. It's a great marketing term as well, which I wish I came up with on purpose (I didn't). But I do think it really works for what I wanna talk about.

00:02:27: Awesome. So if we hear responsive and accessible, a lot of people might think "Okay, those are both important. But do they have something in common? What is the reason to look at them together?" What do you answer to that?

00:02:42: I think the more I've delved into the topic, the more I've found that they do have a lot in common. I find that the way you think about developing a web application to make it responsive is often very similar to the way you think about an application in order to make it accessible. And maybe not always the same thoughts, but they complement each other. If you make an application which is accessible, that means essentially that you are structuring your -- most of the time, the basis is that you're structuring your HTML in a really good way, so that the HTML can be understood from any device or assistive technology or whatever you're using... And that adds a great basis for when you're talking about responsive web applications, which is when you look at what are the content that I have on my page, and how can I make them squish to fill the space that I have?

00:03:51: So the structure of the accessibility, the structure of the HTML really makes a great basis for writing CSS to ensure that the application works on any device. I really like how the two play together.

00:04:09: But they are still independent things. They have something in common, and they have a similar basis, but they still require separate thoughts about them, right?

00:04:20: They do. They are separate concepts, I would say. If you're doing a Venn diagram, where you have accessibility on one side and responsive behavior on another side, there's certain things that would only be dealing with accessibility and certain things that would only be dealing with responsiveness of a website... But it turns out what you can do is you can find a great number of solutions which make it easy to have it be both responsive and accessible at the same time. So you're kind of killing two birds with one stone at that point in time.

00:05:03: Okay, great.

00:05:04: So they're two different things that you need to consider and have in the back of your mind, but they play really well together.

00:05:10: Great. So then let's get started with responsive web design. We both work as consultants, and in my experience, the requirements are often defined by the client, right? A lot of clients say that they don't really need responsive web design. What would you say to that?

00:05:34: I actually made a law, my first law. Joy's first law of web development is that there's no such thing as a non-responsive web application. And I think when clients come with this kind of thought, they are coming from the idea - you know, maybe 10-15 years ago how people built responsive web applications, they built it in a way where it was really expensive. You had to build a whole separate website just for the mobile applications, and then you had a completely separate website for a desktop application. So it was like you're building the same application twice.

00:06:11: So the client thinks "Oh, I'm going to be able to cut costs by saying we don't need responsive behavior", but in my experience, it's just not true that you don't need responsive behavior. In every single instance that I've ever experienced developing a web application, there was always like "Yeah, we don't need a mobile website, because everybody will be accessing this on their desktop. We know all of our users, and they all have a desktop computer." And that's true, until it isn't true. And that's the thing.

00:06:51: So that's a requirement, but then eight months into the project, two years into the project, whenever it occurs, there will always be some kind of requirement that comes. Maybe a user accidentally opens your web application on their tablet or on their phone, and it looks bad. They're gonna think it's broken. They aren't gonna think "This only works on desktop", unless you were crazy enough to write that on your web application “this web applications only supports viewports smaller than 270 pixels”. But that just doesn't actually match with my experience of reality. In reality, users will use your web application everywhere; they'll try to use it everywhere. And even if you're working on a desktop computer, we often make our browsers smaller, and it'd be nice if the content would also move to fit into that smaller browser window, so that we can have more than one window on our desktop. So that's what I'd say - there is just no such thing as a non-responsive web application.

00:08:07: I think this notion is a lot more common in applications that you develop for internal purposes of a customer. So if they previously had some application for their call center or something, that is used by employees, so the employees are the customers, this notion of non-responsive applications is in my experience much more common than customer-facing applications, where this is probably widely accepted, I would say... But even for those applications, for the reasons you mentioned, it doesn't make a lot of sense to not make it responsive.

00:08:52: So I think that it's always funny when you are in a meeting where everyone's sitting there with their smartphone and they say "No, we don't need this." I'm like, "Okay... Do you never want to visit that page with your application?" But I think it's from the mindset of those desktop applications that they are replacing. Beforehand they had maybe something like a Java Swing application, and now they want to replace it with a web application, and maybe that's the reason why they are thinking this way... But I'm not sure.

00:09:25: Yes, but in my experience - and that's my second law of web development; I have to have two... So Joy's second law of web development is that any work you do now to ensure that your web application behaves responsively - it will be appreciated in the future. So when a customer comes to me and says "We only need desktop", I'll say "I don't believe you." But even if I don't tell them that, I will just say "That's not true."

00:09:25: And we don't have to optimize for mobile to make it work on mobile. That's kind of two separate things. So we can make it work for the desktop version the best, but still make it kind of work for mobile; lay the basis, so that it can be used on mobile devices in the future.

00:10:23: I do this in every project I do... The customers come and say "We don't really need responsive behavior." I say "Okay. I'll build it anyway because it's not much harder than building an application which is non-responsive." And then later, they come and they're like "Oh, we have this requirement... The customer just told us they need to use it on their tablets", and then I'm like "Well, it works on your tablets, so it's fine."

00:10:49: I have a little anecdote - we once were working on an application which they said they absolutely know their user group, they never work on a monitor which is less than 27 inches. It might have been 25 inches, or something like that, but it's a very big screen. "So we don't need to optimize for mobile." And then a month before it was supposed to be shown at a really important, um, Messe...? What's Messe in English? I forgot.

00:11:19: Um, road show? Trade show.

00:11:22: Yes, trade show. Sorry. I speak "fluent" Denglish... So it was gonna be shown at a very important trade show, and then the marketing department said "Oh yeah, we bought four iPads to show the application on." They were like, "Oh, no..." But since it worked on iPads, it was fine.

00:11:22: And that's what I'm saying... That's my second law of web development - even if the customer says there's no need for responsive behavior on your web application, just build it anyway. Just do it.

00:11:59: So you said it in a sentence, but can you still explain what do you think is the additional cost that responsive web design has over fixed-width web design nowadays?

00:12:17: I would say it's approximately twice as expensive. And my reasoning for that - this is obviously just a guess, but the reason is that if you build a fixed-width application and then you find out you have responsive behavior, you're basically going to have to rebuild everything from scratch. So the second time around it might be a little bit less expensive, because you already have some basic things in the background; you might not have to redo the whole backend, for instance. But you have to redo all of the work on the frontend in order to get it done... And you have to migrate the whole frontend to the new frontend, and it's just time-consuming and expensive. Whereas if you build in responsive behavior from the very beginning, then that just doesn't happen.

00:13:11: So it may be that there is slight more expense if your developers aren't familiar with responsive web development. There might be a small delay in costs of learning; it's possible. But that learning is kind of a very good investment, in my opinion... Because it's something that will be able to be transferred to any other projects that you have in the future.

00:13:11: So it possibly might be a tiny bit more expensive to do it mobile now; it might take a tiny bit longer to test it on multiple viewports now, but over the long term you will have an application that just works on all different kinds of devices, without having to really think about it... And you won't have to build three different versions of the website for different viewports, you just have one, and its less codebase to maintain in the long-run. You don't have to migrate your application. So it's a lot cheaper.

00:14:18: Awesome. So one of the principles in web development is this approach called mobile-first. Would you say that this is part of your approach, or is it different from your approach?

00:14:31: That's how I would usually build a responsive application. For me, mobile-first basically means I take content, I format it how it would look on mobile first, and then on a desktop device (which has a larger viewport), I can move the content around so that it takes up more space; I have more space to use, so I can restructure the elements better. And that works usually better than the other way around... Because on mobile you're usually placing your content in a vertical column.

00:15:13: If you go to my website, responsibleweb.app, there's a little widget you can play with that kind of shows it. There may be five or six content areas on your mobile site, which on mobile you just place them vertically underneath each other. And then on a desktop, where there's more space, you can then move those areas around in different positions... Which I personally find works a lot better than if you were to say on a desktop device I have these six different areas, and then I have to squish them down to work on a mobile device... Which I guess it would maybe be the same product in the end if your brain works that way, but I personally find it much easier to think the other way around. So I work first for the mobile representation, and then I make it a bit different on a desktop device.

00:16:11: Awesome. So this is because the more capabilities your device has, being screen size, or performance, or stuff like that, the more you add, but it's much harder to take things away later, right?

00:16:25: Yes, exactly.

00:16:26: Okay, awesome. So when I think about responsive web applications, one thing that comes to mind are breakpoints. Especially if you use something like Bootstrap, they have predefined breakpoints for tablet, phone, desktop, big desktop, and so on. Is that the way you would view responsive web design, or is that something that's different from what you would do nowadays?

00:17:01: Yes... Short answer, yes. I'll go into it a bit. The way I develop responsive web applications, which is not -- I don't know, there may be other methods of work, but what I usually do is I first focus on the layout. This is maybe going a little bit to the accessible point, which we will talk about more later... But I look first at the semantic HTML of my layout. What different areas I can use; a main area, a header area, a footer area... You can use asides for sidebar areas... So I look at what content am I really going to have in my application, and I look at it -- we said before I usually do mobile-first, so I'll think "Okay, on mobile these areas will need to be maybe positioned vertically, over each other, and then on desktop they'll need to be positioned differently." So what I do is I have two parts to how I develop responsive web applications. The first is that I use -- I call them responsive layout containers. So I define really with CSS Grid; that's my...

00:18:28: Tool of choice...

00:18:29: CSS of choice... It's pretty easy nowadays with CSS Grid to do this. You can just define, from a certain breakpoint, these layout areas, which are kind of generic. I don't really maybe know what's going to end up in that specific area... But on a container level, I can define "I will have these different areas, and I want them on mobile to be all vertically aligned, and then on the larger viewports I want them to be positioned differently", to maybe have a main content area, to have a sidebar, to have a header... This kind of thing.

00:19:09: So I have usually one breakpoint in my CSS, which means that I say "From this point on, please switch the layout so that then there's a sidebar positioned next to the main content." So then I'll just choose a breakpoint. I don't know if I link it in my article (I don't think I do), but we can link in the show notes - there's one article that I usually use about how we can choose breakpoints based on device size. The best way is to choose a breakpoint which is, for instance, bigger than the biggest tablet portrait, but smaller than the smallest rotated tablet. You can choose a breakpoint in between, so that on most devices you'll have a smooth transition.

00:20:16: So that's what I do. That's the first step I do, is I define really a skeleton, a structure, and then that's my responsive container. Then, what I do is all of the elements that I place in those different areas of my layout, those I call them squishy components. So I make sure those components -- every component will squish to fit the space that's available. So there's a few different ways you can do that. We can maybe go into those later. But the idea is that you have these two parts. So the layout itself is responsive, it will change at a certain breakpoint, and then I have these content areas which are kind of generic HTML containers, and I can just place different HTML components in those layout areas and make sure that the components themselves will squish to fit the space that they have available.

00:21:18: Okay. Before we get into that, can we just recap the CSS Grid part? Can I use that today, or is it still not supported far enough? And what is my fallback if it doesn't?

00:21:35: Yes, that's one of the things that's wonderful about (they call it) progressive enhancement. So CSS Grid is actually supported in every major browser nowadays. It's not supported in Internet Explorer 11, but it is supported on Android telephone, iPhone, all of Firefox, Safari, Chrome, Opera I would assume, Edge... It's supported everywhere, so you can use it. It's been around for at least two years... But the nice thing about CSS is that if CSS Grid isn't supported, the nice thing is that your fallback, which is probably your mobile layout, where the whole elements are placed vertically, one after another - that will still work in Internet Explorer 11. So unless you have a really great reason why you need Internet Explorer 11, which if you have an enterprise customer and they have a pre-installed Internet Explorer 11, that all users use, then yeah, you probably need to maybe reach for some other layout mechanisms... But for just a fallback, the fallback would just be the normal layout, it would just be the vertical layout, which works on your phone, but it also works in a browser which doesn't understand CSS Grid. So it has a nice fallback; you don’t have to worry about using it.

00:23:09: That's great. I find it funny that you said it's there for at least two years... I remember in my first years as a frontend developer, two years where like “it's only there for two years” because browser upgrade cycles were so much slower... But I think especially due to auto-upgrading browser, I think we can switch to newer things much earlier than we could 5-10 years ago... Because they are just getting upgraded. Internet Explorer 6 - it was there for years and years, and there were no upgrades or auto-upgrades to a newer version. There wasn't even a newer version, but nowadays Chrome is getting upgraded like every three weeks, and Firefox is the same thing. As a user, you don't even notice that this is happening, even for enterprise settings where the browser is upgraded. But that's great to know, that it's widely supported.

00:24:07: Yes. But even then, I actually personally like to try out new CSS features. I did a CaSE Podcast with Rachel Andrew (we can link that in the show notes), and she also talked about some newer CSS features... And we can use them as long as we ensure that the base variant also looks good.

00:24:07: I think Andy Bell on Twitter - he talked about minimum viable experience, or something like that... I can look up the tweet, maybe I can find it, and if we can, we can put it in the show notes... But I like this idea that we develop -- the base of our CSS, we can make it look nice, even if we're using some feature on a modern browser which understands aspect ratio, for instance, that just came out. Most browsers even now won't understand it. But we can make it normal without aspect ratio, and then set the CSS rule, and so as soon as the browser does understand it, suddenly you have a better layout without you actually having to do anything or deploy anything.

00:25:19: That's one of my favorite things about CSS, is that you can try out all these new things, and as long as you make sure that the fallback is nice, you don't have to actually worry about a bad user experience for users if they don't have the most modern browser.

00:25:38: Yes. I think a good example for that would be also the navigation you have on the responsible web app site. It doesn't have anything to do with responsive or accessible web apps, but you use an effect where it flows around with a circle... And this would also fall back quite nicely for the older browser, right?

00:25:59: I think so. Now I'm hoping I actually tested that, but I think so, yes... It is a float, so I think that uses CSS Shapes, so if CSS Shapes is not supported, then it would just float as if it were around a box, so I think it would be fine...

00:26:16: If I deactivate it, it's straight down. It's not following the shape, but it's like a straight left and right thing, so I think that works.

00:26:25: Cool. So you mentioned squishy components, which is a pretty nice word, and untranslatable to German...

00:26:34: I've tried though...

00:26:37: How do you implement a squishy component? You already said what it is, but how do you implement it?

00:26:43: Yes, so there's different methods. I don't know if we can link to that specific section in the show notes, or if the users can just go to responsibleweb.app and go to that section... There's different ways. With Flexbox, for instance... Maybe I'll just list out a few. So if you're using Flexbox for displaying content, you can just use flex-wrap, which means that if the items in your Flexbox no longer fit within the space, they'll just wrap on to the next line and continue on the next line.

00:27:18: You can also nest Flexboxes inside of each other. So to get some nice, responsive behavior, you can use Flexbox to make the content just fit in the space that it has available. So I personally like using Flexbox as long as I'm basically styling things in one dimension. There's Flexbox and CSS Grid, so one question some people ask is "When do I use Flexbox and when do I use CSS Grid?" I personally often like to use Flexbox when it's just on one axis. I know I'm either positioning elements horizontally or I'm positioning them vertically. Then Flexbox is quite flexible.

00:27:58: Yes, it makes sense.

00:28:01: Exactly. So that's one option. With Flexbox you have a lot of options for making the content just squished down to fit into the available space. And there's some other options... So there's CSS Grid. It has a function which is called -- I call it an intrinsic grid... But basically, you can use grid template columns that rule with repeat and auto-fill and then no matter how many elements you place inside of this CSS Grid or HTML container, they all just fill the grid. So they'll create a grid with as many columns as are available... Which is really nice if you're doing something like generating a page with a bunch of cards... Things that look like cards, like links to articles, or different things - you can do that with an intrinsic grid. That means that the grid itself will collapse if you make the viewport smaller, and then probably on a mobile grid you will only have one column, but on a larger viewport two, three, four, as many as fit within the space. So that's another method.

00:29:22: One I have on the site - I think I have four in total; this doesn't mean those are the only four that you can use to make a component squishy, but one I use a lot is a horizontal scroll container, which basically means that you just set overflow-x to be auto. That means that the box itself stays the same size as the layout requires, but if you put larger content inside of that box, it'll just activate a scroll bar. I use that a lot when we're developing enterprise applications; we might be developing applications with a lot of tables, and this kind of thing... And tables are notoriously difficult to make squishy. I mean, you can do it, it's just a bit more work. That’s not one of the quick tricks you can use.

00:30:13: Yes.

00:30:15: But often, a table is still -- as long as you can scroll it horizontally, is still usable on a mobile device. So if you just place that table inside of a scrollable container, that means that on a mobile device you can actually still view the content, which is what's important. Otherwise, what happens is if you don't make your component squishy with tables, what will happen is that by default a CSS layout container, if the content doesn't fit in the box - like, if the mobile device says “put this table into this box” and then the table says "No, I'm gonna jump out of the box", then it messes up the whole layout. Usually, the nav bar above doesn't quite fit. It squishes all of the other content to the left, so that it tries to fit the table, or something like that.

00:31:14: Yes. Also, something that happens is that on your phone it's bigger than the screen, for some reason, and then it's a very weird user experience, because you can scroll a bit to the right the entire screen, and everything is a bit off... Which is weird.

00:31:30: Yes, yes. So I just don't like that. It's one of those -- when I see that, I'm like "Nooo...!". Horizontal scroll, at least the content itself is in its own little box that scrolls.

00:31:43: Yes. But what's the experience there with scroll bars? Because nowadays, most browsers hide the scroll bars, for a reason I'm not entirely sure about... Most people expect that they can scroll down the entire page, but do they also expect that they can scroll inside this tiny bar horizontally?

00:32:03: I'm not exactly sure. I feel like -- this is maybe just me as a user. If the content is obviously cut off, then it may look like it's scrollable, and the user may try. You can also add sometimes an internal box shadow to a scrollable container, which makes it look like -- you can see that there might be some content to the right if you scroll.

00:32:31: Oh, interesting.

00:32:33: So that's one thing you can do. You need to just look and see how does it look; is it obvious, can you tell that it's scrollable? If it's not obvious that it's scrollable, you might need to add some kind of shadows or something, or some icon to indicate that they can scroll.

00:32:51: Yes. Maybe that's something you need to do a little user test for your specific application, to see if people understand that they can scroll there.

00:32:59: Yes.

00:33:01: Okay, cool. And the last part are the squishy texts?

00:33:06: Yes, I threw that on there... It's a little bit of a collection of different things which can help your text to break. One promise is if you -- most content is squishy by default, but some text will not break by default. So the typical CSS meme is "CSS is awesome", and awesome is sticking out of the box, because the box has a width, and "awesome" is longer than the width... But there are some methods, some kind of modern CSS. It's hyphens, overflow-wrap, word-wrap, and these things. Word-wrap and word-break are older CSS properties.

00:33:06: And there's some WebKit-specific CSS as well there that I listed on the site, which will just activate hyphenation for your text. So if it does break, then it will break and fit within the box. It is worth noting maybe that you -- I think sometimes the browser decides where it’s hyphenated, so the browsers need to have dictionaries installed sometimes to hyphenate correctly, but I think modern browsers do that pretty well... And even Internet Explorer 11; as long as you're viewing a German website on a German computer, they also do hyphenation.

00:34:43: Okay, awesome. You mentioned that by default the browser is pretty responsive, which is one of the interesting things about web development, because if you don't add any CSS at all, your page will be responsive, right?

00:35:01: Yes.

00:35:03: So it's always kind of our fault if it's not, right?

00:35:06: Yes, for the most part. I mean, most content if it doesn't fit in the box, it just squishes. That's what it does.

00:35:13: Yes, exactly.

00:35:13: You don't usually have to say anything else.

00:35:17: Cool. We covered most of the responsive part... So we have a lot of cool tools; especially Flexbox and CSS Grid can help us a lot...

00:35:27: And I should mention that Chrome is right now on container queries, which is extremely exciting.

00:35:35: Do you want to share your happiness about that?

00:35:38: I'm very excited. Yes, I want to share my happiness. But I don't know the exact spec yet... I've been trying to follow along and read a little bit... But I'm just really excited that it's actually being worked on right now.

00:35:51: Okay. So what is that?

00:35:53: I don't know what the syntax will be, but you'll be able to say @container -- it's similar to how you would write a media query. You would write "this container", you'd write a container, and then like "a min width of 60 pixels" or whatever you're using, or 15 rem... And then you can kind of change the layout of your component based on the amount of space it actually has, not based on the width of the viewport.

00:36:24: What a lot of times will happen is when we're working on this kind of responsive design, we have our responsive layout outside, and then we'll switch from a vertical layout to a layout with a sidebar and a main content area. And there's certain viewports where that main content area is actually smaller than it is on the viewport which is one pixel smaller because of the switch... So with this kind of container queries you would make the component that you've put in that content area - you would make that respond to the width that it has available, and not the width which you have in your viewport. So it's really exciting this one... It's the most request features for CSS for a really long time, so I'm really happy that some people are working on it right now.

00:37:21: It's pretty great. I think the reason it took so long is because it's really complicated to implement it as a very cool feature, that works well, and is also working on slower devices, and stuff like that... So yes, big props to them.

00:37:39: Yes, really. And also, with CSS you have to -- I don't really understand the details that go into the background, but with CSS you have to make sure that there's recursion that could happen if you modify a component, to make sure it doesn't recur endlessly, or the performance isn't horribly bad, or you're triggering layout rewrites every single time you change the layout, this kind of thing. It's a very complicated problem... So it's something that they're working on, and I'm very excited to see what solutions they come up with.

00:38:14: Awesome. Okay, so let's get into accessibility. Accessibility is a broad field. There are different kinds of accessibility needs that people have that visit all web pages... I think your focus is a bit on blind users... Right? There are other accessibility things, like contrast, for example, that are also very important, but that's not your focus in this article, right?

00:38:45: Yes, I listed out some things, but I didn't list out everything you need to be accessible. I tried to make it clear these are just some tips and tricks. One of my main tools for testing accessibility is a screenreader, so a lot of the things that I mention are things that you can easily find out with the screenreader. But it also helps that the two main -- if you can make something screenreader accessible and keyboard accessible, and also pay attention to contrast and things, then you've done a good job. It's a good start.

00:39:26: To be accessible, the tips and tricks that I list on the site are not exhaustive by any means, but they're necessary. I think with learning a little bit, we as developers can stop making stupid mistakes, frankly, and just think about people who might be using our web application who don't use it the same way we do. We can make it maybe 80% accessible. Maybe we don't have the skills to make it 100% perfect, but we can get pretty far if we know some basics, and that's what I wanted to convey on this website.

00:40:16: I feel like I'm learning new things about accessibility all the time, so I had people check if the things I list on the site are correct, and yes, they are... But I also feel like there's other things I don't know, but I feel like those points that I listed are a good starting point as a checklist. If you do these things, you're gonna do better than if you don't do these things.

00:40:46: Yes. I view them as best practices. The same way that you want to have some security best practices because you don't want to make stupid security mistakes. But at some point you need an expert on that does a review or audit of your application, and that will find the last 20% or 10% that are missing. But you don't want to have a security audit that tells you you are vulnerable to CSRF attacks. That would be the baseline that you just want to make sure works without any audits. But if you want to go the extra mile and make it really accessible or really secure, you need an expert to do an audit.

00:41:32: Yes, and that's the thing... With this, when we're developing applications that are accessible, if you want to make sure that your application works for screen readers, you need a screen reader to test it. There's just no way to get around that. But if you learn enough about screen readers to be able to use your web application using a screen reader, then you can make sure for instance that you can navigate to every element with your keyboard.

00:42:07: You can find a lot of really elementary mistakes, and ensure that it's mostly accessible... Because otherwise, if you're asking a screen reader or a user to test your application for you, they may not be able to use it at all. It's possible. And then you don't get any information. But if you can figure out the basic things, then you can focus on the fine-tuning and the user experience.

00:42:07: One thing about accessibility that I like mention is that if you can make a web application accessible, you always - I'm gonna say "always"; it's a very large statement, but... Then the user experience is so much improved for almost any user... If you can make sure that your site is able to be navigated, for instance; you have links to be able to move around your web application. That makes for a great user experience.

00:43:08: This is where accessibility and responsive design can play nicely with each other... If you consider on a mobile device that -- one point I have in this accessible web design section is to use a nav element, which is an HTML element... And you can use that to provide links that allow your user to navigate within the actual page; so not only to other pages on your website, but actually to different heading areas on your page.

00:43:49: This is actually often, I've found -- I've developed a web application with a colleague which we used for our last event, and that was called Spacy; it's an application which we developed so that it's accessible, and it's to collect different ideas from a whole bunch of colleagues, and do open space moderation remotely, so everybody can just put -- like, in an open space you write a topic on a post-it note, and then you place it on the board. Basically, we mocked that up and made it also accessible, so like a web application that does this accessibly. But I've found that there was a lot of overlap between that accessibility and the mobile design of the site.

00:44:43: For instance, with mobile we're also often on a smaller device, for instance, and we may at a certain point -- like, if we're scrolled all the way to the bottom of our device, we may be in an area of the web page where we don't see what happens at the top of the web page. And at that same point, we want to be able to link to that talk, to be able to spring to the top. If we would add that for a screen reader user, for instance, so that they can spring around the page, for mobile devices we can also show that to the user, and it's also helpful. So it improves the overall user experience of the website as well.

00:45:39: Yes. Another example for that would also be the

tag because it's also used by this reader mode. A lot of the web browsers nowadays offer to give you focus on the content... So can you maybe explain what those landmarks are, what they help us do?

00:45:58: Yes, so the main landmarks are main, header and footer.  You can also use aside. Those three, main, header and footer are HTML landmarks, so those should come directly as the direct child of your body element... And what that does is that it will add a layer of navigation to an assistive technology. So for a screen reader or another assistive technology, they will be able to provide a user with a menu of links. "Here's the main content, here's the header..." Maybe shortcuts so they can navigate directly there... So it just adds a layer, it gives information about where that is.

00:46:51: So when we're developing web applications, we could -- a lot of web developers just use a

element for everything. But here we have HTML elements which have a specific purpose, and they add a layer of meaning. It also makes your HTML easier to read, which is an added benefit. So that's what a landmark region is.

00:47:14: Cool.

00:47:16: I think there may be other landmarks that you can also add to your HTML markup. You can research it.

00:47:25: Cool. I think one of the things that is different for a screen reader user than for a sighted user is that you cannot glimpse into other areas of the page quite easily. So you need some way to jump between things or get an overview of your web page. How can we help users doing that within our web applications?

00:47:48: Well, I usually use links to do that. That would mean that I just place a link -- if I think the user might need to get from this area of my web application to this area of my web application, I can add a...

00:48:08: An anchor link?

00:48:10: Anchor link, thank you... So I add an ID to that specific section that I want to link to, and then I can add an anchor link, linking with the hash. And then if the user clicks on the link, automatically they will move to that area of the web application. As I said, that's something that also improves the usability for mobile as well, if you do that.

00:48:37: Yes. Very cool. And headings - do they also help with that? Can they offer some structure, or something?

00:48:46: Yes, they offer structure in the sense that they offer the information structure. I think with a screen reader you can view an overview of all the headings on the page. So it's good to use headings which are obvious what it means... It actually describes what it is at that specific part on the page. And what's really important with headings is that you don't ever, ever, ever skip heading levels. I'm saying that because I am a developer and I know the first time I was working with headings, I was like "Okay, I'm gonna use this h1 tag, but the h2 is too big. It visually just doesn't look right, so I'm going to use an h4." And then I was like, how bad is this? I didn't understand, so I had to read up on it... I didn't understand that the heading levels are not intended to look like anything. The h2>levels are intended to provide a clear documented structure of your documents... So it should be like your table of contents, should be your heading levels.

00:49:59: You should have one h1 for the page. Then you have different heading levels, h2 elements, which are maybe the main sections. Then under h2 levels you can have maybe a few h3 to break it up... But never skip from an h1 directly to an h4, because what happens - if you're going through the content and the user is only just has the content, and they go from the h1 level to h4, they're gonna think that they're missing two heading levels... Like, "Oh, where has the content gone?" They think you made a mistake. It's very possible that someone will get confused. So it's very important...

00:50:47: What you can do instead is you style your headings based on -- you can style an h2 to look like an h6. It doesn't have to be big, but it needs to be an h2. That's the point.

00:51:05: Cool. One thing that is also quite inaccessible for a lot of people are forms, because there are certain trends right now that make them even more inaccessible than they used to be... Can you give us a few hints about how to design our forms in a way that they are accessible to people?

00:51:31: Yes. So the one trick -- well, not trick; it's common sense... But always use a label element. It's one thing that is very important, and one thing that is often done wrong... And that is that use a label element for every input field that you have. You can either wrap your input field, like add a label as a container around your input field with the text, so that you know that the label belongs to the input. Or even a little bit better is if you have a label which uses the for attribute and an ID. The for attribute should reference the ID of the input field that it is referencing.

00:52:24: That's very important, because when someone is navigating the page - first of all for screen reader users, if you navigate the page and you just land inside an input field, if the input field has a label, that label will be read out to the user. So it's something extra; it tells the user what this input field does. Because otherwise if you're in an input field, it'll just say "Edit text". In Voice Over for example and you're like "Well, that's not helpful. What text am I editing?" So adding the label will tell you what text you're editing.

00:53:02: But not only that, it's also extremely important for users who -- just any user, frankly... But it's especially important for users who may have difficulty concentrating, for instance... Because with labels which don't have forms, that usually means they misuse the placeholder attribute to make the text in that label appear in the input field. And then when the user clicks in the field, that text disappears.

00:53:38: So if a user has difficulty concentrating, what may happen is they click in the field, the text disappears, and then they're like "Wait, what am I doing? What was it that I was supposed to input here?"

00:53:38: And the other thing, if you think about frankly just the usability of a page, if you put in -- you know, they fill out the whole form, maybe they submit it, and something's wrong. The typical user experience is that the whole form will come back and it'll show you the fields which are wrong. But at that point do you remember what you put in the field? So you might get like a "Please input a number" or something, and you're like "But I don't remember what field it was. What number am I supposed to put in?"

00:54:31: So just always use a label with input fields... And remember, placeholders are not intended to be labels. They were intended to give maybe some example information. If the field is "Input name", you might put "Joy Heron" as a placeholder to show that this is the format that we would expect. It's supposed to be of help, but it's not supposed to be the main instructions.

00:54:31: This is especially difficult because there's some designers who use – they’re like “input fields are boring”... So they just decided to be cool with their design, and what they did is there's a common design pattern which is that when you place your cursor, the label is shown as the text, it's shown in the place where you see the text. When the user clicks in there, the label moves up and becomes a little smaller.

00:55:44: But it's really difficult... I mean, theoretically, you could do that with the actual label element, but it's really difficult, and most people don't. And that's a big, big problem. The other problem with that is that when the text is in the input field, it also looks like it's filled already. So it's bad usability.

00:55:44: I would say, for the most part, just leave it -- the typical form field looks like a form field, which means that the label is there, and then an input field falls directly under it, it's left-aligned, the input field looks like an input field, which means it's a box, it looks like you can click in it... These kinds of things. So this is a common usability thing. We shouldn't think "It's boring, so let's make some really cool design." Frankly, when it comes to form fields, boring is really, really good, because it means that it’ll be easier for users to figure out if it's so boring that it's obvious how to use it. That should be the goal for forms - it's just so boring that it's obvious how to fill out the form.

00:57:09: Yes, because boring is easy to understand, right?

00:57:14: Yes. And even using the patterns that we all know about, that's what it means.

00:57:17: Yes, exactly. Especially the floating label pattern, or however you want to call it - I find it so weird, because some people put the label inside the field because they want to save space, which I find to be not a great reason, but an understandable reason... But if you do the floating label thing, you're already reserving space for that label, because you are floating it up there anyway, so why not put it there from the beginning? This is something I find quite hard to understand, but... Yeah, this is some trend, so we need to accept that... But we don't need to accept that in the scope of accessibility.

00:58:01: Okay, cool. So this helps us to build more accessible forms. Another topic are things that you want to show and hide. I have a very long page, and I have certain areas where I say, "This is additional information that you only need to look at if you really want to", and one pattern for that are accordions. What can I do to build a good accordion component, so that it's also usable for screenreader users?

00:58:36: Well, there's a newer HTML element, which if you aren't supporting Internet Explorer 11, you could use it, and that's the details element. That actually provides exactly this behavior. The thing is if you are showing and hiding content for users visually, you probably want to show and hide that same content for someone who is not accessing your site visually, because it's probably not that important.

00:58:36: You add the details element, and then you can add a summary inside... That just adds like a toggle field which will collapse and expand the content. That's actually the easiest way. It works all the time, as long as the HTML element is supported, which it is in all browsers. Currently, it'd be nice if you could get away with only using that. I haven't actually tried using only that in projects yet...

00:59:42: Usually, we have to implement this behavior in some way... On the site I have a custom element that I've defined, and I basically copy it between projects. And what it is - it's just a toggle button, and what it does is I add the toggle button to the page, and when JavaScript is enabled, it will toggle the content. So I add an attribute to the button, say the data target, with maybe an href or something, or maybe a CSS selector... But what that does is it just will hide and collapse the content that it references.

01:00:36: What it does is it also uses the aria-expanded attribute. The aria-expanded attribute is an attribute that you add to a button to tell the button what state is the UI currently in. I've seen that mistake made a few times, as someone thought that the aria-expanded attribute was what you put on the content to tell if the content was expanded, and that's not what it is. The aria-expanded attribute tells the button, it adds an information for screenreaders which will tell the screenreader is it collapsed or expanded currently. If it's collapsed, the user knows they can expand it, and if it's expanded, they can collapse it. So I have a little custom element that you can look at on the website.

01:01:21: One thing I like to do also - with this accordion element, I personally like to hide the toggle button by default, and I show the content by default. And then if JavaScript is activated, I have the JavaScript remove the hidden field from the button, and then hide the content and make it the toggle button. What that does is if the browser doesn't support JavaScript - usually, they support JavaScript to some extent, but if it doesn't support that flavor of JavaScript, or there's some JavaScript error in your bundle, or something else, or you just weren't able to download the JavaScript because your internet connection is really bad - in that instance, your content will still be available. So that's a little bit of progressive enhancement.

01:02:30: For instance, the website itself, responsibleweb.app - it uses this component in the menu, but I have an old Android device and I tested it on the Android device, and "it didn't work", because my Android device doesn't support custom element; it's a bit older. And I thought it was just great, because it actually looked okay. I was like, "Oh, good. I don't have to do anything." This toggle button failed, but in this instance, I can just use modern JavaScript, and for older Android browsers - they won't actually know that it was supposed to collapse, so I don't really have to do anything.

01:03:12: Yes, that's pretty cool. One thing that I always want to say about accordions is that if you include an accordion, you should probably think about why are you hiding this content; if it's not that important, does it need to be on the page? Or maybe could you put it on a different page and link to it? I always feel like accordions are a bit overused, but that's just my personal taste.

01:03:42: Yes... I mean, they're often used for menu buttons.

01:03:43: Yes, that's true.

01:03:44: And that's when you usually do want --

01:03:48: Yes, agreed.

01:03:49: But even then, if your hamburger menu button doesn't work on your phone, but you still can see the menu items, then it's fine.

01:04:04: Yes, it's true. Cool. One important thing always - there might be certain things on the page that should only be visible to sighted people, and other things that should only be visible to screenreader users. What is the technique there?

01:04:27: First of all, sometimes there's elements in our page (icons, different things) which we add to make it more clear to the users what it does... But a screenreader user may already have all the context they need, so they don't need extra information. So what we can do then is we can use a visually hidden CSS class, or a mixin, or whatever we're using, to just hide it visually, but still make it available in the accessibility tree. The problem is if we were to use "display: none", then it would not only remove it from the visual page, it would also remove it from the screenreader.

01:05:17: So I always have a helper class -- I showed a CSS snippet, the one I usually use, on the page. There's just some different things you can do to hide it visually. I think it's like position: absolute, making it one pixel high, overflow: hidden, all these different things.

01:05:45: Cool. The last topic I would see is focus. I think that's especially a problem with JavaScript-heavy applications that create accessibility problems. What do I need to know about focus as like a 101 course?

01:06:05: I will answer that, but I actually will go back -- because I talked about hiding content visually, but I didn't talk about the other part, which is adding contextual information only for screenreaders. We can do that either by adding a span attribute or a paragraph attribute to our page with that visually hidden class, but we can also use the aria-labelledby attribute on our HTML to add information, if it's necessary.

01:06:05: So if it is an icon that we need to tell the user how to use the icon, and they can't see it, if they can't guess that it's an upload icon, we should add a label to that. Frankly, we should add a label to it even visually in that context... But if we do have information which we need to add contextual information with a screenreader, we can use an aria-label, or just a visually hidden element.

01:07:13: Back to focus... If we don't do anything with JavaScript, then just leave it... By default, browsers add a focus style to form elements. So when you tab through a web page, it will add a focus to -- usually, I think it's form elements and buttons. I've configured my Safari -- you can configure browsers so that they also will focus on links by default... But usually, the default focus style is like a blue ring. And sometimes a designer will be like "Oh, that's so ugly...! You have to get rid of that." In that instance, what you can tell the designer is they need to find that great focus style.

01:08:05: Only remove a focus style if you have something which clearly also indicates to the user that it focuses. But often, I just leave it, frankly. It's not too big of a hassle. I don't think it's usually worth the effort of testing focus styles in all the different browser combinations that there could be. It would make me really nervous to overwrite the default focus styles personally. Usually, I find that prefer to invest my time in a few other things, just because I'm scared, I'll miss out on some browser somewhere, and the focus styles won't work so correctly; that kind of scares me.

01:08:54: On this website though, I think I did use a focus style, maybe... Yeah. But I used the same one; I think I used outline as well, but I just styled it differently. I think I used the dash, and maybe a different color of blue... But it's still a visual focus style.

01:08:54: The important thing with that is that when a user is a keyboard user, they will navigate the page, and they need to know where they're on the page. If you are tabbing through the page and you don't know which form field you're in, you just can't use the page. So that's the one thing.

01:09:35: Then if you do use JavaScript -- I mean, I do use JavaScript for web applications, I just try to minimize it... But when you do certain things with JavaScript, you also need to consider focus. I have an example that I linked - if you're doing pagination with JavaScript and you click on a Show More button, if I am in this context, I click a button, and I can't tell that something happened, how do I know that something happened? So in that instance, it's probably best to move the focus to the new item that's loaded in that instance. And then you can test it to make sure it works; of course, test, test, test. But don't move the focus unless you really have a good reason for doing it.

01:10:40: If you're loading new content and if the user clicks on this button and this new content loads, and it'll be useful for the user to move to that content, you can do that. At that point, you should also add a label, a visually-hidden label, which will tell the user that they moved, so that they know, mimicking this behavior.

01:11:10: Cool. Wrapping up both points, you should always reconsider if you are thinking about replacing a default thing that the browser offers... Because the browser vendors did a lot of work to make them accessible, and so on; if you replace them without thinking too much about them, you will probably make a mistake, and you should probably consider the costs of reimplementing them in an accessible way before doing that. I think that's important.

01:11:43: Yes. Maybe to wrap up, I think in general, if you're developing applications in this way, you're developing based on browser standards... I like to think about it as you're developing -- it's easier to support browsers that are old. Especially HTML and CSS are both very stable, so if an older browser sees something that it doesn't understand, it ignores it, if it's HTML and CSS. So it's easier to create a minimum viable experience with HTML and CSS which works, and then you can support almost any browser, going really far back, with very minimal effort... But also, it's developing your application for the future. Browsers are well-known for being backwards-compatible. So if something has made it into the HTML spec or into the CSS spec and I use it in my application and it works now, it will work in 10-15 years, maybe even 20 years. How many technologies can we say that about?

01:13:02: Yes...

01:13:05: So this is one of the things - I love developing web applications this way, because it's much easier to develop for the past; even if we are using JavaScript, we use polyfills. In the future, we can just delete those polyfills; so, we're upgrading our application by deleting stuff, which is great... And we're also thinking forward. Our application will look the same and work the same in five years as it does today.

01:13:36: Awesome. My personal prediction is also that more people will become screenreader users in the future, because we use things like Siri and so on to read stuff to us... So I think this is also preparing your page for the future to make them usable by voice assistants, or however you want to call them.

01:13:36: Okay, Joy, thank you so much for this great overview of those two very important topics. I hope to get you back on the podcast someday. Thanks for your time, and thanks to all the listeners for their time. See you next time. Bye-bye!

01:13:36: Of course.