I’ve spent the better part of the last seven years presenting at all kind of conferences, meetups and client meetings and I’ve learned a lot along the way. I learned about different needs of different audiences and how to prepare your talk to make it as easy as possible for organisers to work with you. More importantly, though, I learned how to ensure that my presentations can be understood, don’t offend and work in even the worst organised environments.
In order to share this knowledge, and to remind myself of the necessities I put together a checklist to fill out before my talks. Not all of these bits are applicable to the talk you may give, but it is a good reminder of what you can do to help others understand what you do. And to make sure you can show your company what you did.
Here is a verbatim transcript of what we talked about:
Hi, Chris. We are here at Prismic, very happy to have you there. Could you maybe first introduce yourself?
Hello, I’m Chris. I’m a principal software developer at Microsoft, and I’m dealing with all matters web there, ‘cause I’ve been doing it for 20 years, and I love the web.
So if it’s safe for you, in your case for your product, to actually use these already and also links through the documentation of these things links through the problems that they may have and links through the W3C standard that is actually their source of truth for everything but it’s not as easy to understand. So these are the main resources that I think are a great way for people to get started. And of course look around for videos on YouTube and conference videos because all of them are available for free. Every conference spends a lot of money producing these things and giving them out, so it’s kinda weird ‘cause people watching this right now so this kinda matter. But look at these resources and make sure you look at the date as well ‘cause some of them get outdated rather quickly, but something like MDN the great thing is it’s not a Mozilla product, it’s basically an independent product that people from Microsoft, Google, Apple, Samsung, whoever is doing something on the web are contributing to that one. We realize this is the one resource. We want to keep up-to-date, so this is a great place to start.
Okay, cool. So once they have looked this knowledge, where should they start, which tool should they use?
Okay, and one last question is, what would you start with like as your first project?
Okay, cool. Well thank you very much for being there.
Here is a verbatim transcript of what we talked about:
So I’m here at Prismic, with Chris Heilmann. Chris, can you introduce a little bit yourself what you’ve been doing?
I’ve been web developing for 20 years, now I’m a Principal Software Developer for Microsoft working on all web tooling there and the browser.
Right. You are working on EDGE, right? – Yes.
This is the feel of control, right? You can control every little detail.
So it what the case, right? It’s by block align, all the kind of thing, yeah. You had to kind of always know exactly how the browsers are behaving and now it’s a standard, there’s Flexbox, you express what you want and it’s implemented.
So the browser will help us with what? in CSS?
In CSS it helps us with the rendering of different interfaces, if you use grid, if you use Flexbox, it also helps us with the animations. So it’s helps us with the coloring. It helps with the fonts, all the things that you actually want to have. And it helps us with caching as well. A CSS file can get cached and can get reused by the browser. Whereas if you render something, every single time on every single frame differently, because you want to have full control of your animation, it cannot get cached and it will have to download the whole bunch every single time just because you want that control.
Right. So like for instance, here’s an example, why is it problematic to have a SPAN? And you know, kind of put a link, an action on it, an event on it and make it look as a button? What could go wrong?
A SPAN does nothing. A DIV has no semantic meaning. A DIV could be anything. It’s a placeholder. If think about it, it’s a variable, it has been undefined in CSS, so to say. Not really, but it’s nothing. Whereas a button already when you tell a button in HTML, the browser renders it as something clickable, it tells somebody who is blind that this is something clickable as well. It gives you a depressed state. It gives you a state that is invalid. It gives you a state where it’s greyed out that you can just control with an attribute as well, Like all the different UX states of a button that you have to define if you use a , are already given to you in the browser because it’s built-in. Of course, it might not be to your liking the way it looks, but in the past we couldn’t style it. Nowadays, styling of buttons is completely possible, across all the browsers that we have nowadays as well.
Another example is that in input fields for select for instance, it’s like the first time, I noticed it, a long timeago, whenever you click on a select box instead of trying, in your mobile phone, to kind of find the actual state that you want to select, it opens something down, which is much bigger, which is like much more visible.
frameworks and components instead of using like CSS and HTML What is the right decision? Is it the size of the team, the size of a project?*
It’s more an architectural decision than anything else. If your environment, if what you build is consisting of lots of little changing parts, that are not interacting with each other and are not and cannot interact with each other, then the component framework makes so much more sense because that’s what it was built for. The web was not built as a platform to do these kinds of things as of yet. We’re working on standards to think about it in that direction as well.
Just like – Web component of course—- Web component
It makes sense. Thanks Chris
Disclaimer: the following is not a dig at JSFest, I just used their website as a demo at the event. It is a common problem many people have on their sites, so it is a good example to use.
However, we can really make it hard for keyboard and screenreader users when we forget to set the focus to the element we scrolled to. Just because it is in the viewport, doesn’t mean the keyboard focus moved there.
What does this mean? Let’s take a look at this screencast. As a keyboard user, you need to hit “tab” seven times to reach the “prices” link. Activating it does scroll the correct section into view. However, if all you can do is hit tab and you can’t see the change, it needs an additional 107(!) “tab”s to times to really reach the section.
The remedy is easy:
Ensure that your target sections of your menu are keyboard accessible landmarks in the document with IDs. This also has the benefit that anyone following a “yoursite.com#target” link will get to that section
After you scrolled to the section, move the keyboard focus programmatically from the menu item to the target section using focus() and – if needed – by setting a tabIndex.
If you want to test this on your own sites, install the accessibility insights extension for Chrome or (new) Edge.
You will get a heart icon in your browser and a choice of tools to run on the current site:
Select the “Ad hoc tools” to get the extension to overlay accessibility issues on the current document:
Once you turned on the “Tab Stops” option you get a confirmation that the extension is running:
Hitting tab now will start showing you the tab stop journey across your document, which helps you find issues like these. Often these are easy to fix, and make a huge difference.
Posted in General | Comments Off on Common accessibility issue: moving to a page section without shifting keyboard focus