Some video editing tips that I wrote down a few years ago, and just rediscovered on a post it note in a drawer. I wrote these after having recorded my @LI_learning courses, and after doing many hours of video for clients on their accessibility enablement videos.

A🧵: 1. Write a script, in more detail than you think you need. You'll ad lib some anyway, but you'll thank yourself later when you've got most of it done in advance.

(I had an outline for a script for recording, and then struggled on the fly over lines repeatedly. Just script it)

I’m already loving this week so far @salesforce - async week has allowed me to make progress on things that needed more significant dedicated blocks of time, and to work without interruption.

salesforce.com/blog/meeting-f… My hope is that experiments like this lead to methods and changes we can make to the ways we work at any time, not just during async weeks.

Reason number 398 that accessible components don't guarantee an overall accessible interface:

Working with an accessible slide-out panel component, as the base, designers/devs decide that for this application they want it to be "open by default" The "normal use" of the component assumes that the person activates the panel using a clear call to action, then gets feedback on where they are when the focus moves there. The "back" control makes perfect sense to them, as they were the ones that opened it.

Self-audio-describe your presentations and teaching sessions to make them more accessible and inclusive. Some examples:

Rather than saying “As you can see here” try “On the left side of the screen is…” Rather than saying “For this equation, how would you approach solving it?” try “For this equation, 2y equals x + 19, how would you approach solving it?”

I've heard this often: "But we CAN'T do any testing with people with disabilities at this stage... it's a prototype and you can't use it with a screen reader"

For your consideration:

1. This statement assumes that the only reason to include people with disabilities is to test. 2. This assumes that the only feedback you should be getting is from people that use screen readers.

3. This assumes that because it doesn't work with a screen reader one can't get valuable feedback on it from a person that does use a screen reader.

A slide I use. Design process and inclusion of people with disabilities in the design process: usually once, at the end, as testers, or as usability study participants.

Instead of seeing this as an expression of process, reframe it as an expression of Power. In the above, the designer/org makes all the decisions. They decide what the project is, what design to use, how to implement it, and how people with disabilities are allowed to contribute to the work.

My 20.5 old daughter just logged into an online system at her college.

It was a system that I named (or at least contributed greatly to the name).

She got an error message and an image.

That I created.

In 2001 or 2002.

Just kinda letting that sink in a little. I am 90% certain that I used Macromedia Fireworks 2.0 to create the image.

Accessibility was never a "nice to have" thing. It has always been a "must have" but people/orgs deprioritized it. Made it a thing for phase 2. A thing they can add later. As we go through this public health crisis, people are realizing it is an absolute MUST HAVE for all things. Amidst all the uncertainty and increased focus on public health, people will be asked to make all materials accessible. That will include web sites that are providing critical info about disease, its spread, and prevention measures. It will include social media posts...

You simply cannot expect that 2 days of training will get you to where you need to be when it comes to something complex.

You'd never expect to be a great designer after a 2-day training. You spend thousands of hours working on your design skills over a period of years. You'd never expect to be a great developer after a 2-day training.

You learn new programming languages, new constructs, and new ways of thinking about abstract problem solving, and develop those over thousands of hours over a period of years.

Some collected thoughts for designers for when you're contemplating and exploring error message treatments... Here's some accessibility considerations for your design:

#UX #a11y #accessibility #thread 1. Is your error messaging strategy relying on colour to show error states? If so, think of other ways of conveying error state - iconography, and words that support that use of colour.

Note: I'm not saying "Don't use colour!" I'm saying use other methods in addition to colour.

Brain: don’t buy those notebooks. You already have enough to last until 2037.

Me: can I just look?

Brain: ok. Just look.

Me: oooooooh... I’ve never seen one like that before!!

Brain: stop.

Me: wow… dots AND lines. That’s a must have.

Brain: that’s it. We’re out.

#addict Me: ok ok. No notebooks. I get it.

Brain: much better. 2037 wasn’t a joke.

Me: I know, I know.

Also me: So.... what about these pens over here?

I remember two moments very early on in my teaching career that led me to REALLY understand the importance of keyboard accessibility. They turned out to be pivotal moments that made web accessibility feel completely natural to me. The first? In 1995 I bought my own computer, and noticed that there were really tiny screws on the back that I could remove. When it was time to get online, I bought my own modem (US Robotics 14.4 fax internal model) and endeavoured to install it myself.

OK, I get it. You created a search results page using the latest single page app hotness. But here's the deal. When I click on one of the items to see its details and then go back to the search results page, here's what I expect: 1. You need to remember the change that I made to the "number of items per page" dropdown. If you don't, I was on page 1 of 2, and now I'm on page who knows what of who knows how many.

If you're creating a tool that posts things on the web, or allows a person to create content, please make sure that your tool(s) pay attention to the Authoring Tool Accessibility Guidelines (ATAG):

w3.org/TR/ATAG20/ First, your tool should be accessible itself.
Second, your tool needs to facilitate authors creating accessible content, and should guide them towards it.