I am Marcy Sutton. Ask me anything.

Senior front-end engineer & accessibility advocate at DequeSystems. axeCore team member, eggheadio contributor. Dirtbag bike racer, music junkie, dog lover.

Ask Marcy Sutton about:

  • Web Accessibility
  • CSS
  • JavaScript
  • General Front-end Development
  • Petting dogs 🐶
  • Bike Racing 🚴
  • Life Pro Tips 🙆
Ask a Question

48 discussions

Why just following semantic web standards not enough for web accessibility? Why do a web developer has to add additional data attributes like aria?

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.

Reply to this…

Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!

  • 💬 Ask programming questions without being judged

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 More than 500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Create my profile

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:

Reply to this…

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

Reply to this…

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.

Reply to this…

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.

Reply to this…

Load more responses