And I've also done research with the University of Adelaide in the area of youth with autism, and looking at ways we can kind of engage them with entrepreneurships and things like that. So I've also done a bit of user research with Mozilla around the Firefox OS product which is sadly no longer there.
So it's I guess kind of why I'm talking about accessibility. So what is accessibility? Well I guess there's a couple of different perspectives. So if we're looking at it from a legal perspective, it's all about regulation and compliance.
If we're looking at it from a human perspective, it's about enabling an enhancing access for all types of people and assistive tools. If we're looking at it from a client perspective, then it's really making our code cater for a wider audience, therefore creating a larger user base, therefore selling to more people or having more users. From the developer perspective, though, it's all about the code.
(chucking) And we're all developers here and we're at the code conference, so that's what we're going to talk about.
Sadly, I'm not going to go too much into any live coding or anything like that because, as you will see, this is not a simple area. So this brings us to what I call the modern day dilemma, which John touched on a bit.
So yesterday we heard how JavaScript is growing from being something that we really use on the client side to validate information to something that's not just being used on the service side but it's being used in robots, it's being put on mobile apps, IOT devices, et cetera. Anywhere you go, you can find JavaScript these days. So JavaScript has made its way into an integral part of the modern web, and it seems to be the strongest language at the moment going forward into the future for the web.
So the modern day web is built on JavaScript frameworks. So yeah, we went from an obscure validation code to actually running a hell of a lot of things. So this then brings us to the myth, but JavaScript can't be made accessible.
Well, we all know that this is a myth, right? Any bad code is bad code.
If you write bad JavaScript, it's not going to be accessible, if you write bad HTML, it's not going to be accessible.
If you write bad CSS, it's not even going to be accessible. So it's kind of a real myth, right? But myths tend to be based in some kind of truth. So let's explore just a little bit why this became permeated through the web culture.
So I guess I'm going to explain something that you all know. So on the back end, so if we're looking at, I guess, what a lot of our sites are doing at the moment, at the back end we've got JavaScript code that's running, that JavaScript code runs through various processes, and it outputs HTML.
The HTML is sent through down to the browser. On the browser, we then have it sent down with HTML, JavaScript, CSS, images, et cetera.
We then have further manipulation that occurs on the browser through JavaScript libraries, manipulating the dom. The browser receives HTML and it turns it into tokens for the dom.
So if you're, most of us here would be aware of the dom. Basically, dom realistically is the programmatical interface for a browser. The dom then creates an accessibility tree from that tokens that it's received.
The HTML is rendered to the browser and the assistive technologies read the HTML. So we can see all through this process, it's HTML that we're looking at at the end. HTML and accessibility, well we're talking a lot about standards here these last two days.
So HTML's a standard, it's been around for a very long time. So HTML elements really aren't there to make things look good, that's what CSS is for. HTML elements were created to describe the information that we're actually reading, so you think of P for paragraph, block quote, image, A for links.
Native HTML elements are implicit.
They declare their roles, name, properties, and states to the dom and the accessibility API. Aria tags have been added, which we will look at in a little bit, to add to this, to add to HTML elements, but realistically native HTML elements contain all that information there.
And assistive tools really do rely on native HTML. It is really the only standard.
If you've ever used screen readers, there is no screen reader standard.
So the accessibility API's all we've got.
So this is the accessibility stack.
So if we're going around into the early days of computers where we actually didn't really have an accessibility API. So first of all, the accessibility API came out for operating systems that then got extended into browser. So if we're having a look at it, we've got an accessibility API, we've got assistive technologies, browser, and operating system.
And the dom, so if we go back here, we see browser, accessibility API.
So the dom has accessibility API tree but where the myth comes from that JavaScript is not accessible is because JavaScript cannot talk to the accessibility API. JavaScript can talk to the dom, it can manipulate the dom, but it can never manipulate the accessibility API. So there is some truth to that myth.
So JavaScript and HTML, then.
Well as we've already said, screen readers and other tools really read the HTML elements.
So back in JavaScript frameworks output these HTML elements. They're translated, as we said.
JavaScript can manipulate the tokens but it can't manipulate the accessibility API. And before, when I said HTML elements are implicit, well there was a little bit of a gotcha there because div and spans are not implicit, they are semantically neutral.
So the problem that we have with JavaScript frameworks is they like to pump everything out in divs or spans. Seems great, except if you're actually trying to interpret that into the accessibility API because they're semantically neutral.
So a screen reader's actually just going to see that anything in that is plain text, even if you've got an A link in it, for example. But I write JavaScript, not HTML, is what I get a lot of times when I go in to do refrectoring projects.
Yeah, that's fine, you do write JavaScript, but the user sees the HTML, the browser interprets the HTML and screen readers use and need that accessibility API. So it's tricky, right, because JavaScript's not talking to it and we can't manipulate it.
But this is why Aria was born.
So Aria was born as a way to solve that problem. Now hopefully in the future, possibly with AI we might be able to actually talk to the accessibility API, but that's not any time in the very close future. There's some W3C people here, they might be able to give you some more info on that. It has been spoken about, but it's not a simple thing. So let's I guess have a really quick look at some of that. So if we see we've got, in our user agent land, JavaScript acts as the controller, and it's manipulating the dom tokens.
It is event-driven, and we can create new widgets on the fly, we can domatically change things.
The accessibility API however, is not.
It is implied hierarchy, so it takes the hierarchy of the dom and kind of implies that in the accessibility API. It has state and property events and roles. And these then communicate through to the assistive technology what to do and how to do it. So where we're looking at a div, if we're, for example, as we said, a lot of these frameworks are pumping out divs, they might pump out divs instead of a table element for a table.
So in that case, you've really got to be starting to use the Aria roles and other things to actually tell the accessibility API what it is. So what is actually important to the accessibility API then? So names are important.
Now, names, you know, my name is Aimee, there's John over there.
Name is a way that an element declares itself to the assistive technology.
So, for example, if we're declaring a name, I've got a form. So the form label tag becomes the name for the accessible-associated input.
So then on the assistive technology, I can actually say, drink box, check.
And I can actually call it by that, rather than having to fumble around with it. Names, as I said, it's kind of an interesting one because it really comes around to how you formulate that HTML.
Now roles is something that we should all know because roles have been around for a while and they're now becoming very present in a lot of our front-end frameworks, like Bootstrap, et cetera. So role actually declares the element type. So when we were showing the accessibility stack before, when we actually stipulate a role menu, that accessibility API knows at an operating system level it's going to treat a menu and the browser at the menu in a similar way, and there's implied states and properties with that. So by actually using a native element, we don't even need to add that much onto it for an assistive technology to be able to understand what we're talking about.
So if we look here, we've got the input type checkbox, that's the actual role that it's telling us there. States.
So states convey the current state of an element, right? States are dynamic, they can change, and this is when we really start getting into rich application stuff.
So here we're looking at a state where we're actually saying checked.
Properties.
Properties are attributes that really, I guess, describe the given nature of that object.
They are less likely to change, as well.
So a state will change, a property will not change. You'll find states and properties are grouped by widget types, live regions, drag and drop, and relationship. The main ones that we work with in brochureware websites is widget types.
Widget types are actually all around the gooey and the UI, and relate to items around that.
Live region is where we're looking at something like a banner or a timer or a search box. And drag and drop is pretty much drag and drop, and relationships is how we actually describe parent-child relationships.
So if we look at it pretty quickly there, we've got the device, so we're looking at a search box, we've got a name, it's a search, at the moment the value is none, it's role is a button, it's state is default and it's focusable, and the description is search this site, and we're giving it an Aria-live of polite, which means telling the screen reader there not to consistently update it, but just to update it when the actual reader's not reading other things.
So what does this mean for custom elements and web components? Which is what I've kind of came here to talk about. Custom elements across frameworks is actually, you're creating that element, right? You're creating a new HTML element, so all of a sudden you're out of that implicit area, you're out of that space where automatically the browser knows that this is a link, and I'm going to call it a link and it's going to lead me somewhere.
So that's really a very important thing to think about. They're very, very, very powerful JavaScript print frameworks.
We can prototype very quickly in them.
They're a huge buzzword with our clients and management. Some frameworks, we're going to have a little bit of a look at some of them, some frameworks do this a little bit better than others, but realistically they kind of all suffer from the same thing.
It really depends on how you're addressing the Aria because there is, as we'll see, not one framework that's really got it.
We don't have to worry about HTML because we're JavaScript developers, we always have to actually worry about HTML because that's the way that we're communicating to the browser and we're also communicating to the user visually and to the assistive technology. Now I got a lot to download, so I hope that I'm not going too fast.
Now let's just have, I guess, a really quick look at Angular.
So I would actually say that Angular is probably one of the more advanced, it's also been around for a little bit longer, there's a lot of people on the team that have an accessibility background as well. So Angular, as they all do, allows you to create custom elements.
So you must declare the state, role, and the properties for those elements.
Now it has the N G Aria initiative, which is actually quite interesting.
It enables some common Aria attributes, not all of them, but it will enable enough to kind of get you through what you need to. And it uses a Google Material Design approach as Polymer does, so it kind of keeps in similar with some of the way it's doing things.
So Angular, as we said, has the N G Aria.
So what we can do is we can include this module into our app and we see up here where we're actually saying on the checkbox N G disabled, that actually prints out to the browser as Aria disabled equals true.
So where you're actually using those N G tags, they will come out as Aria tags.
Angular and the dom.
The thing that we're going to see across all of these is we've come to this world now where we're emulating the dom and we've got the shadow dom, the shady dom, and all the other doms.
And this actually really, really becomes a problem because we're no longer talking directly to the dom. And remember, we cannot manipulate that accessibility API. All we can ever do is update and append.
So all we can ever do is, for example, say actually I want this to be disabled.
Because of the use of the shadow doms, this can become very, very tricky.
Now, the cool thing about Angular is you can actually drop that, so you can actually start working back within the dom again and not actually trying to mess around with a shadow dom. And where that becomes really hard is, it actually implements itself differently across browsers as well.
So if you've ever tried to do screen reader testing, you'll see that when you actually are working with something that has polyfills or the shadow dom, there's really a hard way to keep that consistency. And it's for a certain reason.
So, if we look at Ember.
Now, I must admit, Ember's one I haven't played as much with.
Ember allows you to create your own custom elements. Once again, we've got to establish our role, states, and properties.
Now it does have role built into it, which is really handy because we can get a lot of that out of that.
But we do need to really look at how we're doing tab index and key downs, and things like that.
And the reason that that occurs is because, oh there is an ally initiative, by the way, for Ember. So why does that kind of happen? Well, the problem is how we're doing our data bindings. So we're actually in Ember, we're talking to a virtual dom, virtual dom which does batch processing to update that virtual dom before it then speaks to the dom before it then creates the accessibility API. (chuckling) All of this in your browser.
So data bindings and transitions means because of how that's working within the virtual dom, your focus is lost and focus is very, very important not just for keyboard users, because not everybody uses a mouse, but actually when it comes to the assistive technology and where it needs to know how to read and what to read. So Ember ally is actually working on a replacement for this, so you replace outlet with focusing outlet. I've got really not much time left, so I've got to hurry up. So we've got Ember button, there's a little example there. You can see that we have to do the programmatic tab index. React and ally.
React allows you to create custom HTML elements and, as we've said, it's got the virtual dom that does the batch updating. It has a more advanced Aria feature set, sorry, Ember has an emulated and React has the virtual. React does have an ally tool that performs a check and kind of gives you a little bit of an update, what's happening there.
Polymer and ally.
Polymer's really quite hard because we're dealing with the polyfill, but once again, having Google support and having a very large group of people there focused on it, it's actually got a little bit more, it's trying to really, I guess, kind of work towards having more accessibility in there, certainly no where near along as Angular is. And because it is working on the web components frame, that web components concept, we're really looking at polyfills, and once again, our light dom and our shadow dom.
So once again our tab focus becomes really, really important because the parent-child architecture that we see in the shadow dom or the virtual doms in that does not always represent what the dom will receive as its parent-child connection.
So you can start to see that this becomes a really big problem.
These things are great for CSS, woo! Not great for accessibility though.
So the key problems are inherent to all.
There really is no one framework that I could say is above and beyond the rest.
You are going to have to make compensation for using them because they all have the same problem.
They lack native elements.
Now the accessibility community has really been heavy on these frameworks about that so you are starting to see them start to use more native elements and not just spit out a bunch of divs.
But it's tricky.
And they actually, when you're using them as a developer, as we all know, it really kind of forces you into using some of these custom elements.
So we kind of start having to get into the area of really using our Aria tags, which means that we've got to start understanding these. So how do we do it? Well, we love and we're understanding and loving web standards. And I cannot stress that enough.
So we have WCAG, we've got WAG at the top, there you go, there's the W3C, we've got WCAG, which is the guidelines for accessibility standards. Wai-Aria is what we've talked about.
It's a tool set of tags that we can use for each interface interactions and also for when we're using, when we're actually trying to declare things that don't have roles and properties and states. We really need to understand our HTML elements and use them. Validating your code.
I've actually worked with a few people recently that are like, we never validate on W3C.
Validate your code.
That is actually an important part of the WCAG standard is actually having validated HTML and CSS code. And I guess, really check that code as well. And you know, if you're wondering which element to use best, look it up, the standards are there.
When we're doing this, as we've said, there's the API, the accessibility API.
The accessibility API has roles, so when we're creating these elements, we really want to be doing a one-to-one matching of these roles.
So if we kind of, I guess, try and condense this down and finish up, we can look at some top tips. As we said before, there is no state roles or properties so we have to declare them.
But the overuse of Aria tags can actually become really verbose and you can actually throw out the screen reader more than helping it.
So really look at those Aria tags and how you're using them. Try not to do an overuse of them.
Control of the tab focus for the keyboard can be problematic when we're rebuilding that dom, so that's something that we've really got to check, and each framework has a different way to implement tab index.
We have to take a more precise approach to the Aria roles and we've really kind of, I guess, got to look at what that element is and what it's actual purpose is and functionality is for the end user and making sure that we declare and state that to the dom.
It's impossible to use native elements all the time, but where we can use a native element, use a native element. If you were doing a spreadsheet or tabula data for example, use a table.
Trying to mimic that same experience in divs, in custom elements, is going to be very, very tricky. It is not a simple task at all.
It is not going to take you a day, it's not even going to take you a week.
So that's something that we've really go to think about. And when we do focus on the leading bleeding edge technologies, so when we focus on the latest frameworks that come out, then we are going to be struggling more with accessibility than we would in some of the older frameworks that have conquered some of these things.
So quick approaches, as we've said, native elements. Custom checkboxes, so this is, I guess, a little thing here. So when we're creating, if we create a custom checkbox, give it the role, tell it it's checked, tell it when it's disabled, tell if it's required, wire up the keyboard events.
These are the kind of things that we have to be doing for custom elements. So you can start to see there's actually a lot of additional work that we need there. Add focus only when you're not using a link, so that's one thing that you do see a lot of is people just go crazy.
Oh, I've learned Aria roles so now I'm going to just tell this that it's a link. Well we know it's a link if it's an A tag.
So you've really only got to be stating what something is when you're not using those native elements, when you're using divs or spans.
Tab index zero is what you want to use.
You'll not want to get into anything where you're going higher than one.
There's cases where I've come to refrect a code where to get over something, some developers have had to put in 10 different tab indexes, and this isn't even on an interactive site, this is just on an information site.
That kind of thing is really going to trip up the screen readers.
So to, I guess, sum it up, accessibility engineering, and I've dumped a lot of information, and gone probably quite a bit fast, but accessibility engineering is not simple, it's a moving target.
It's never ever going to be finished.
You can write a piece of code, hand it to someone, it can meet a compliance requirement, and then tomorrow someone else can change something in it and that compliance requirement is gone.
Or they could add some content in it as a content editor and they actually haven't used proper markup in their content, so you can lose it from that. So it's a moving target.
Technology is not perfect.
We aren't in this state where we're going to ever get a perfect accessible application.
And you can sit there and throw 50 bodies at it for months, but it's really, really hard to get perfect. Because when we're looking at cross browser support, we're actually looking at cross browser and cross screen reader support in all of them. So it starts getting quite complex when we're trying to approach this.
But any little thing that we can get in there helps. We're mainly targeting screen readers at the moment, so a lot of other assistive technologies we're still just not up there with yet.
And one thing I guess I like to point out is that every human being is different.
And isn't that a wonderful thing? (laughs) And that's the thing.
So what's going to suit somebody or some disability is not necessarily going to be good for everything else. So that's why it is this moving target, and it's never going to be perfect.
So you're never going to get a perfect accessible app. But that's okay because you might just make it slightly accessible and, for the person that's using that assistive technologies, you've really changed the way they're interacting with your information.
So I hope I haven't dumped too much or gone too fast. It was really tricky trying to create this. I thought it would be a little bit easier, and then I'm like, we'll I don't even know if the audience knows about Aria.
So it probably should be a split talk in the future. But I guess what I want to say is go forth and make the web accessible.
There is tools out there that you can use to check. There is communities out there that you can use to talk to, and really just research.
This information is not simple, we don't get taught this whenever we do any of our courses, something I hopefully would like to see changed in Australia.
So don't feel bad, and enjoy yourself on the accessible route. Thank you.
(applause) (funky electronic music)
