If you had the time to just give one life pro tip, from which everyone here could benefit from what would it be?
Also, how did you get into bike racing? :)
My biggest life pro tip would be to try and engineer your life around what makes you the most happy. For me, that means getting away from the computer and outside into nature in all seasons, particularly for snowboarding and mountain biking (my favorite sports).
I sat in an office from 9-5 Monday-Friday in downtown Seattle for many seasons watching snowy powder days pass me by, and it made me sad every single time, like I was missing out on life. Yet, it was important ground-work for learning how to be an effective front-end developer. Eventually, as I got more senior in my career, I was able to take a remote job and move outside of the city so I no longer had to fight traffic to do my favorite non-work activities. I'm now under an hour's drive to a legendary ski area and countless hiking trails, making my seasonal outdoor dreams much more attainable. That balance helps me be an effective web developer and team member because I come back refreshed and happy that I'm living the best life I can while my health is good.
On bike racing: I got into cyclocross because it looked fun and there was beer involved. I met a rad group of folks who said if I raced singlespeed I could be on their team. I don't race a whole lot since I enjoy being solitary or in small groups a lot more. But bike racing is a fantastic community that I would recommend to anyone.
How do I get started with doing web accessibility testing? Is there a standard checklist one can adhere to?
There was a very similar question earlier, you can find my answer here: https://hashnode.com/ama/with-marcy-sutton-ciu7ybenl0235za53kdqpw0f5#ciudv1ov30k5neq53ifj07rjr
I would start by tabbing through a page with the keyboard to make sure you know where you are on the page (using the default CSS outline or custom :focus styles) and that all actions can be completed without a mouse. You could also use one of the aXe extensions to run an audit: http://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US
Check out my videos on Egghead.io, which may help with various accessible development topics: https://egghead.io/courses/start-building-accessible-web-applications-today
Hey Marcy! thanks for hosting the AMA...
I'm interested in knowing how modern CSS affects accessibility.
With things like flexbox and grid layout, the visual layout can be completely different from the DOM tree and can really mess up with accessibility functions like screen readers.
Do you think as we are going advanced with our layouts, we are making web less accessible?
As far as I know, sadly the answer is yes (right now). I think browsers need to do more work to make flex and grid layouts more accessible by default. For example, if you reverse the order of flex items they will impact the reading order but not the tab order. So a keyboard or screen reader user might be confused about the order of content on a page. There has been some discussion around this recently, and I think Firefox even did the right thing at one point–I'm unsure of the status without doing some testing myself. But here are some links for further information:
Why just following semantic web standards not enough for web accessibility? Why do a web developer has to add additional data attributes like
My egghead video on Intro to ARIA might answer that question: https://egghead.io/lessons/html-5-intro-to-aria
Short answer: you should always start with semantic HTML because of what you get for free (keyboard focusability and semantics, style and behavior built-in). Sometimes, though, ARIA is necessary to expose accessibility information on custom elements. It doesn't add any behavior to the DOM, though, it only impacts assistive devices. It's one tool to have in your toolbox, knowing that you should reach for native elements first so you aren't having to recreate what browsers give you.
"I learned we can all make a big difference on the web for people with disabilities by designing and developing inclusively." I can't agree more.
There is so much being written on Progressive Web Apps, Mobile First Design; but there is a serious lack of content when it comes to "Accesibility First Design"; what do you think of it?
What are a few things that can we do to design websites that are inclusive to blind people?
My hope is that accessibility is integrated into each of those topics so it doesn't get left behind. Of course, as an accessibility advocate, I would hope accessibility would be first, but the challenge is that everything can't be first. Security first, mobile first, offline-first...which one is actually first depends on how the learner got there. For that reason, I try to speak and write about how accessibility is relevant to other topics, since there are always interesting points to be made–hence my talks on Mobile Web Accessibility, Accessibility and Performance and Accessibility of the Shadow DOM / Web Components. As new technologies come about, we will always have the opportunity to highlight their impact on accessibility. Always. Despite being told "accessibility has been solved" by a conference CFP early in my career, it hasn't been solved. We get to keep bringing it up, and that's what makes it interesting.
A few things you can do to design websites that are inclusive to the blind and visually impaired: turn off your screen and ditch your mouse. Follow an accessibility design checklist like this one from WebAIM: http://webaim.org/resources/designers/. For development, use accessibility testing tools such as aXe and the Chrome Accessibility Inspector.
But you should also keep in mind that accessibility is more broad than blindness and low vision–there are also many people with physical, hearing and cognitive disabilities. That's where testing tools and checklists can help, in addition to usability testing with actual people with disabilities.
What are your thoughts on CSS3 speech spec? Do you think browsers should take a step to implement it soon?
The CSS Speech Module sounds like such a fantastic idea, I really wish it had gained traction–but it hasn't. Here's some language I found from the W3C about the status:
Speech contains properties to specify how a document is rendered by a speech synthesizer: volume, voice, speed, pitch, cues, pauses, etc. There was already an ACSS (Aural CSS) module in CSS2, but it was never correctly implemented and it was not compatible with the Speech Synthesis Markup Language (SSML), W3C's language for controlling speech synthesizers. The ACSS module of CSS2 has therefore been split in two parts: speech (for actual speech, compatible with SSML) and audio (for sound effects on other devices). The speech properties in level 3 will be similar to those in level 2, but have different values. (The old properties can still be used with the deprecated 'aural' media type, but the new ones should be used inside the new 'speech' medium, as well as in style sheets for 'all' media.)
I don't think there has been enough implementer interest and public outcry to help these gain traction. A lot more attention seems to be paid these days to the Web Speech APIs. This goes to show that if something is specified, we have to tell browser vendors that we WANT and NEED those features, so they prioritize them. Otherwise they might not ever get adopted.
What are your best tips for getting people on board with web accessibility?
How do you create the empathy required for really committing to this?
Any "Do this" / "Don't do that" you recommend when talking with people about this issue?
The biggest don't I've found: don't yell at people, tell them they're wrong, or say their code is terrible (even if it is). Do bring people along when educating them about accessibility. Try to find something they did well and lead with that–it will soften the blow when you point out what could be improved.
Two effective approaches I've found to creating empathy are 1) making it about people with disabilities by showing examples of how someone is impacted, and 2) appealing to their own sense of humanity with a bit of "selfish accessibility". Make designers and developers aware that they or someone close to them could be impacted by a lack of accessibility–there is a wide spectrum of possibilities, from senior citizens to low vision to a new baby occupying one arm. The Microsoft Inlusive Design Toolkit does a good job of articulating these points: https://www.microsoft.com/en-us/design/practice#howwemake-section
What are a few of your favorite books on Web Accessibility, and on the web, in general, general technical books?
Here are a few books I would recommend, there are absolutely many more but most of these are on my bookshelf:
- Inclusive Design Patterns
- Apps for All: Coding Accessible Web Applications
- Practical Approaches for Building Accessible Websites
- Don’t Make Me Think
- A Web for Everyone
- The Pragmatic Programmer
- Code: The Hidden Language of Computer Hardware and Software
Hi Marcy! Glad to see you here :)
What are your thoughts on material design on web? As it was originally meant for touch interfaces, does it do justice to say.. People with low vision?
The teams at Google have put in a lot of thought in regards to accessibility for Material Design and its various implementations built mostly in-house (such as Material Design Lite and Angular Material, the latter of which I worked on for almost a year).
That said, there are still color contrast issues with the main themes that could impact low vision users. I know it was reported to Google's design team internally, but the websites built with Material Design still have contrast issues (as one example). That's why it's so important to choose an accessible color palette early on–once your brand guide has shipped with certain colors, it's really difficult to change them.
What are your favorite resources on web accessibility? Can you point me to some?
I put a link together for this very question: https://marcysutton.com/web-accessibility-resources/
What are some of the sites that you love that meet the modern accessibility standards?
Great question! There are some really good examples these days–I catalog them on my blog, Accessibility Wins: https://a11ywins.tumblr.com/
It's a bit unfortunate that it took a legal guideline to get there (the Air Carrier Access Act update), but US airlines are doing a better job with accessibility these days. Alaska Airlines is a great example: https://www.alaskaair.com/
Simply Accessible's website is a fantastic example of accessible RWD: http://simplyaccessible.com/
What are your thoughts about Atomic CSS (acss.io) and other similar frameworks that uses single purpose styling units applied via classes?
Have you ever used them in production or recommended it to your clients?
I haven't used Atomic CSS personally, so I can't comment on that. But–I can say that pattern libraries present a wonderful opportunity to integrate accessibility early on. By making sure each pattern has accessibility built-in to it, you can prevent every developer implementing it from having to figure out those basic requirements later on. The same goes for all CSS- and JS-driven UI frameworks. By tackling accessibility as part of the library, every development consumer and end-user can reap the benefits.
What's your favorite time of the day to be outside on a hike?
Definitely in the afternoon! Trails are quite popular where I live in Washington State, so trailhead parking lots are often full early in the day. Depending on the time of year, I will wait until later for people to clear out and I can park right in front. Plus, the trail magic that happens at golden hour and late in the afternoon is one of my favorite things in the entire world.
If i'm drinking while programming, what is the single most important feature (across the accessibility spectrum) that might help me as much as my users? This is a serious question.
If you're drinking while programming, or holding a baby, or if you have a broken/amputated arm, you would rely heavily on the use of one hand. Therefore, the keyboard is the most important tool. That means you'll want to test with the keyboard to ensure interactive controls like links and buttons are focusable, and they have a visible focus style. You should always know where you are on a page using the keyboard only and you should be able to accomplish anything a mouse user can.
What is your “accessibility” pet peeve?
This is a tough line to walk since I try not to focus on the negative. But something that gets me riled up every time is inaccessible demos showing other developers how to code. Often the message is "we're focusing on something specific, accessibility wasn't the purpose of it", or "it's just a demo", but every unlabeled form control or image missing an alt attribute teaches an antipattern and further cements people's lackadaisical attitude about accessibility basics.
Rule of thumb: if you're demonstrating anything related to a User Interface, accessibility is a fundamental requirement. Approach every demo as a teaching moment!
Accessibility is the most ignored aspect that a developer thinks of while learning. I too had a hard time learning about accessibility during my formative years.
How do you propose that it become a more central part to the learning curve of a developer?
Education is definitely the missing piece, and each person teaching front-end development skills has a responsibility to cover accessibility basics. That means at least mentioning the need for it in UI-focused classes, articles, books, demos, and conference talks. I don't think every educator has to become an accessibility expert, but they need to know enough to not contribute anti-patterns.
Another way we could move the needle on developer skill building would be to require accessibility in more front-end job descriptions. That way, each of us would figure out that it's something we need to know in order to get the job. That's the goal of the Teach Access organization: http://teachaccess.org/
What inspired you to become a Web Accessibility Advocate?
I worked at an agency with a client who had gone through a lawsuit for accessibility (Target, the US retailer). That meant, as a front-end developer, I was obligated to learn about accessibility and work with Target's QA and accessibility teams to ensure our deliverables were accessible. I met some fantastic people at Target who were blind and visually impaired, and my love for accessibility grew.
I learned we can all make a big difference on the web for people with disabilities by designing and developing inclusively. In those early days, I pushed for accessibility in other business verticals such as gaming and arts websites, even if it wasn't a requirement in the contract. There were easy wins I could implement all over the place, such as form labels, alt text and button / link text. And once that door was open, I saw many opportunities for growth. Years later, it's still my favorite web development topic!
What are the some of the WCAG features that excite you?
As someone who works on accessibility tools for developers, there are a few groups and projects surrounding WCAG that have me really excited. (WCAG stands for the Web Content Accessibility Guidelines, a standard set of success criteria for meeting accessibility)
- Accessibility Conformance Testing: https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/ACT_Overview_-_What_is_ACT
- Auto-WCAG Community Group: https://www.w3.org/community/auto-wcag/
To describe the relationship (taken from my colleague Wilco Fiers, who works on both), the Accessibility Conformance Testing Task Force will focus on standardizing a format of accessibility test rules, while Auto-WCAG will continue to develop test rules according to that new standard. So all of the developer tools created for automated accessibility testing will have applicable standards, making them more consistent and reliable for both development consumers and end-users.
Do you have any recommendations to track people with disabilities on websites, to better the experience for them? How to go about measuring stats like how many people are using screen-readers, using accessibility plugins, etc...
There are big privacy concerns with user tracking. Most people with disabilities do not want to be tracked, as it means they have to disclose they have a disability in a space where otherwise they can go without waving a big white flag (or cane) that says "HI, I'M DISABLED!" The best thing we have is the WebAIM Screen Reader survey, in which users self-report what browsers and assistive technologies they use:
One thing you could do is add event-level tracking in your own analytics to measure accessibility features such as skip links and keyboard-interactive controls. But that would be specific to your own application.
What are your thoughts on accessibility impacting (positively or negatively) performance? Follow-up — Can you even call something performant if it's not accessible? Thank you!
Performance is something to optimize after all of the basics are in place, including (but not limited to) accessibility. It seems premature to optimize something without basic keyboard and screen reader support. There are some improvements and optimizations that can be made for accessibility early on, however, such as using native HTML elements to limit the amount of code that gets sent over the wire. My research and conference talks might be relevant as I go into what can impact both keyboard and screen reader users:
Is there a simple checklist that all websites can follow to make their websites more accessible?
There are quite a few! The biggest one is WCAG 2.0, the standard guidelines for accessibility compliance: https://www.w3.org/TR/WCAG20/
That can be a bit hard to digest, though, so there are additional tools that may help. I work on aXe, an accessibility auditing tool that includes browser extensions and various APIs. aXe can audit any local or remote webpage and provide you with a list of issues that map to WCAG success criteria and best practices.
aXe Chrome: http://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US aXe Firefox: https://addons.mozilla.org/en-us/firefox/addon/axe-devtools/ axe-core API: https://github.com/dequelabs/axe-core
How to decide how disabled users would like to interact with computers and smartphones?
For example: In mobile apps, do blind users want an explicit “close” button for a small non-modal dialog (tooltip), or is it enough to have them find the area “outside” the dialog using browse by touch, which they can then tap to dismiss.
I would start by following known ARIA patterns which are rooted in years of user research and best practice. This link has information on modal and non-modal dialogs: http://w3c.github.io/aria-practices/
Following best practices can give you a solid baseline for accessible components. But it is also very useful to do user testing with people with disabilities on your own application to get feedback on a particular thing you've created. Access Works at Knowbility is one organization that can help you find usability test subjects: http://www.access-works.knowbility.org/
Good to see you here. I have read most of your article on Egghead.
My question to you is : How important do you think accessibility is in this IoT era? Do you think web developers who generally skip accessibility factor while developing web apps are committing a huge crime?
Accessibility is always important, and it provides innovation opportunities! The Internet of Things is a really new area; we definitely need more accessibility research on it. IoT devices should be multimodal so many people can use them, like providing audio output on a Nest thermostat. I suppose many of these devices are paired with mobile apps which can be made accessible in various ways. A mobile app is an interface a person with a disability can use if designed and built accessibly, opening doors to all kinds of IoT devices. It's interesting, and I'd like to learn more about it.