slideshare quotation-marks triangle book file-text2 file-picture file-music file-play file-video location calendar search wrench cogs stats-dots hammer2 menu download2 question cross enter google-plus facebook instagram twitter medium linkedin drupal quotes-close

Last week I went to my first @a11yLondon meetup and I thought I'd tell you about it. It was the group's 19th and I've been meaning to go for ages, and now I'll be going each month!

The meetup was live streamed on YouTube, but there's nothing better than meeting new people, learning their stories and asking questions in person.

The meetup is the second biggest @a11y[location] meetup in the world. Chicago is the biggest but we're catching them up. It's organised by Alistair Duggin, Head of Accessibility at GDS and sponsored by Barclays Access who do a lot of accessibility work; providing food, drinks and live captions by @mycleartext. It was hosted at @sainsburys and what a wonderful venue!

The first speaker was Paul Bepey, Head of Assistive Tech Strategy at the BBC. As a visually impaired person, he never thought he'd get a job like this. Coming from a programming background, he landed the role because the BBC's values boast inclusivity, ensuring internal systems are accessible to employees. He spoke about how they have manual tests for their approved software, and they run only N-1 (latest version plus the last) for all software. When a person [with a disability] joins, they gather their requirements, software/hardware is purchased and the existing software must work with the new. That's a lot of testing. It takes about 8 weeks.

Paul expressed concern about cloud-based software and how it's hard for the BBC to use because an update (which the end user doesn't know about) could break accessibility and suddenly the software isn't usable to staff. He was talking software rather than websites, but it was interesting to think of the internal side of a11y.

Some of us suffer from migraines; Redmine doesn't work so well with the brightness down and we can fix this. Important information fields are scattered, meaning a person squinting will move their head more to see the screen. We can ensure we don't use repetitive patterns that trigger a migraine. If doing something like this makes our lives better then really, everyone is winning: us, our clients - we have no idea if any of these people have a disability, they could be the ones that email us instead of using Redmine because it's easier for them.

The second talk was the AMAZING Derek Featherstone, my new favourite speaker. He has tutorials on LinkedIn, which the team have started working on. He made inclusive design and accessibility sound manageable, interesting and fun in a way I've been trying to explain for a while now! The core of his talk was about considering the extremes to make life better for everyone. Short people like me and tall people like Greg alike!

Andre the giant is pretty big… in this photo, he is holding a breakfast cereal for a very entertaining 1980s advert. The individual cereal is 1 inch wide, his finger pad is… a tad bigger. If Andre the giant had an Apple watch, how would he be able to use it seeing as the screen is marginally wider than that… (surely he just duct tapes an iPhone X to his wrist?).

Derek showed us many manual tests they do in their inclusive design process to ensure they are designing things correctly. Such as the Straw test - looking through a straw at the screen to resemble that of someone with low vision, the Dory test - someone who forgets, has cognitive disabilities might forget important information whilst filling out a form. They create a set of tests as projects come up depending on the user research, they then become a library of tests to use on other similar projects, these tests then get tested with real users. Nothing replaces real users, but this does reduce early mistakes. I can't find the examples of these tests online but I will be building a set of resources we can all use.

He reiterated a designer's favourite question over and over. "Why?" "Why are we doing it? what is the problem we are trying to solve?" …By asking this question the content on a page, its layout and functionality is all greatly improved because the tests allowed them to think of the extreme cases.

Accessibility is an outcome. Inclusive design is a process.