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:

marcysutton.com/accessibility-and-performance https://www.youtube.com/watch?v=RkbyP-OJRgw

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.

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:

http://webaim.org/projects/screenreadersurvey6/

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.

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.

JavaScript framework docs and some textbooks come to mind as missed teaching opportunities–the anti-patterns presented in those resources become really hard to unlearn. If you're in a position to contribute back, issues and pull requests on open source projects like Angular are a great way to improve the learning environment for those coming after you. Blogging about what you've learned is great, too!

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/

Here are a few books I would recommend, there are absolutely many more but most of these are on my bookshelf:

Accessibility Related

• 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

General Programming

• The Pragmatic Programmer
• Code: The Hidden Language of Computer Hardware and Software
• Eloquent JavaScript

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.

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.

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.

There was a very similar question earlier, you can find my answer here: hashnode.com/ama/with-marcy-sutton-ciu7ybenl0235z…

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: chrome.google.com/webstore/detail/axe/lhdoppojpmn…

Check out my videos on Egghead.io, which may help with various accessible development topics: egghead.io/courses/start-building-accessible-web-…

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.

https://www.instagram.com/p/BIRic9VAYo-/

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: microsoft.com/en-us/design/practice

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.

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:

• tink.uk/flexbox-the-keyboard-navigation-disconnect
• wiki.csswg.org/spec/css3-flexbox/accessibility

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: chrome.google.com/webstore/detail/axe/lhdoppojpmn… aXe Firefox: addons.mozilla.org/en-us/firefox/addon/axe-devtoo… axe-core API: https://github.com/dequelabs/axe-core

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!

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/

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: w3.org/WAI/GL/task-forces/conformance-testing/wik…
• 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.

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!

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 put a link together for this very question: marcysutton.com/web-accessibility-resources

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/

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.