Unmeasurable Accessibility: The Case for Inclusive Design

Talk by Darice de Cuba / View Slides

Digital accessibility is more than just coding your website according to WCAG, passing tool tests and being usable with screen readers. It’s about inclusive design, which starts on day one of your project. In my talk I show based on personal stories and real life examples how accessibility is part of inclusive design. That it takes more than just valid and accessible code to make your website or product usable for everyone. How diversity helps you avoid pitfalls when designing websites and services. 

Questions on “Unmeasurable Accessibility: The Case for Inclusive Design

    1. While I’m not a font expert. When I design longread pages I keep a maximum of 4 fonts. 1 for the headers, 1 for the body text, 1 for blockquotes. And I use a monotype font for image and illustration captions.

      I always check design resources for best font pairings. To make sure they don’t clash.

  1. Do you see enough changes in Diversity in relation to digital accessibility? How can we improve and what area needs it most? What is the first thing you address when you start a project?

    1. I think we still have a way to go on diveristy on all areas, digital and otherwise. I believe that one should consider diversity on day one of starting a project or team. Let go of the believe of hiring people “who fit wih our work culture”. You want people with different perspective than you have. People outside your bubble. Your team, project or product is not going to be diverse if everyone for example, and just an example: is male, abled, white, likes soccer and the team building outing is a soccer game and beers afterwards.

      Imagine the next project of that team is building an app for pregnant women to track their pregancy. Or an hospital app for patients to access their appointments, results, keep track of questions they have for their doctors and such. There are many issues to such apps that won’t even occur to the team. Imagine if the team had women, disabled people, POC, different reiligion. You’ll start the project way ahead.

  2. Thank you for your talk Darice. As you said, YouTube autocaptioning is not perfect. But, can those captions used as a reference to edit and fix all errors?

    1. Yes! It saves time to have a basis with the time annotations. You’ll just have to go through all the text and correct them where needed. It will save time instead of starting from scratch.

    1. I have no hands on experience with this. But I’ll say probably, you’ll have to “burn” the captions in the video file you will embed with HTML. An .mp4 or .avi file for example, you’ll need to add the captions with a movie editor and save the video with them.

    1. No.

      Links always need to have descriptive text. For screenreader users and abled users. No one likes being confused with where “here” goes to.

    1. A huge let down from Google. I have read the supposed reason they are discontinuing them is spam. I find it hard to believe that a company like Google with the best engineers in the world can’t solve that problem and instead are removing an accessible functionality on which millions of people depend on.

  3. I actually guided students last semester on a captions project. I saw many creative examples. It was for a think outside the box kinda project. But right now in the real world:

    Simple is always best. Sans-serif for spoken text. White on black or yellow on black. Italics for sound and music.

    For transcripts: Make the name of the speakers bold and maybe with a light coloured background. Enough white space between paragraphs of speakers. A comfortable line-height for sentences. Almost black colored (I prefer #222) text on white background. If you use dark contrast, dark grey background and white text.