footer: Kara Carrell | TableXI 2020 | @KaraAJC | kara.codes slidenumbers: true
^ OK everyone, I'm kara Carrell, I use she/they pronouns, and today I'm going to talk to you about the 5 things I do to make sites more accessible.
^ Step one! It might sound obvious, but I know that since I've not yet gotten a handle on everything that makes a site accessible, I make sure that I google what I can do to make the thing i'm doing more accessible. This has been useful recently when doing work on SVGs that i'm still learning about in general, but I found a few things I can do to make them more accessible, like making sure there's a title, or a nearby label if it's an informational icon. Doing this is also me continuing to listen to the disability community about their needs, and doing right by that community is important.
| HOW | WHY |
|---|---|
| 1: LMGTFY 😄 | 1: I've learned from others' expertise |
| 2: find dev-specific resources | 2: To find a solution quickly |
| 3: if it's an img, table, form, or layout, imma double check | 3: Never hurts to check your own work |
^ What I mean here is that much of what we are given with HTML5 is built with accessibility in mind, so using as much of that will give us what we need, without doing much at all! If I'm working on views especially if i'm writing haml, I double check that I'm not adding more divs where other tags could be used instead. It makes our code easier to maintain as well, because we're writing in context by using semantic HTML.
| HOW | WHY |
|---|---|
1: in haml I always try to use %tag |
1: A11y is built in! |
| 2: If I see a div that can be better defined, I change it | 2: Makes code easier to read |
| 3: i.e. main, header, section | 3: ... and easier to change |
^ Sometimes, divs still need to be used, and sometimes context is just not super clear, so in those cases, I try to make sure I'm using the appropriate html tags and attributes to give assistive technologies what they need to help someone get all the context they need. Role and title attributes can be vital when that context cant be derived from semantic HTML, and if there's ever a table in code, it should have a caption, sometimes images need captions too. we can't leave the information up to interpretation.
| HOW | WHY |
|---|---|
1: Add role attribute to div elements |
1: Expressing intent helps assistive technologies |
2: i.e. img role=presentation or div role=button |
2: ...also helps other devs |
3: i.e. th role=col/row |
3: ...and helps the client! |
^ Now that I've been trying to do this, I've gotten into the habit of asking myself a few questions to check what I'm doing, so I know to look for the right answers in terms of what a11y implementation I should do. The biggest question is "is what I'm doing adding information, is it functional? or is this aesthetic? furthermore, will my aesthetic change be obfuscating information? sometimes alt tags for example, arent needed, for presentational background images, where others are trying to convey meaning, so it's important to make sure everyone's in on the joke, as they say. You'll also notice some testing guides will ask you questions instead of saying "this is the way" because it depends on your intent, and no one can know that but you (or in MANY cases, the client).
| HOW | WHY |
|---|---|
| 1: For visual things like icons, images | 1: Semantic HTML requires meaning |
| 2: Ask clients for clarification | 2: Folks can be missing out on info OR |
| 3: Implement accordingly | 3: Folks can be overwhelmed with unnecessary info |
^ I've added this step to my PR template in github as well, but just as we have githooks like rubocop and linters to check if we semicoloned our lines and dotted our methods, there are tools you can use to run the page through to make sure there isnt more you can be doing to make the site more accessible. And that's all!!!
| HOW | WHY |
|---|---|
| 1: tota11y | 1: Hammering in WHY something is wrong helps you learn |
| 2: AXE beta | 2: Don't want to add to the problem |
| 3: Microsoft Insights | 3: If I can fix something around the code I'm changing, why not? |
^ GOTCHA!! there's much much more than 5 things! and systematically, now that i've had exposure to over 25 repositories internally, I think these are things that keep coming up for me that i want all of us to work on getting right before it ends up on my plate in maintenance, and though I love having the opportunities to learn, we're sending experiences out to folks every time we launch a project, and we want all of those experiences to be good ones.
Page titlesare IMPORTANT!Set language, it helps!- Don't let abstract writing cloud us from implementing a11y
Cough Haml, Cough React - Good tip:
Zoom to 200%, are things still workable?
- Google Now To Remember Later
- Use HTML's built-in A11y
- Add attributes when you have to (particularly,
role & title) - Ask yourself: Is this
information, oraesthetic? - Use a linter to check yo'self, before you wreck yo'self & others!
^ Join the channel in slack, and check out the work that folks have done internally so far, props to the brink team, props to alex, props to Matt, props to robin, props to Aly
- Join the #accessibility channel in Slack
- Check out the work that's been documented so far.
- JUST DO IT.