The 'viral' tital for the show: "All the javascript in the world won't save you!" Really enjoyed the discussion on accessibility in general, and the technical sides you speak about in particular.
I think something missing from a lot of Accessibility videos is actually using the page/component with a screen reader. I think this is a crucial part of building accessible components. I often do integration accessibility tests for work and it becomes clear that developers never tried using the component with a screen reader. Understanding how users that use screen readers use sites and components is really important. It's another level of learning that a lot of developers and designers don't want to deal with. Then they have an accessibility audit and get 200 issues noting that the site/component doesn't work well with a screen reader. Sometimes shrugging the issues off noting "I used semantic markup, aria-roles and it passes our required static analysis test". Semantic markup, correct aria-roles and static-analysis tools get you a lot of the way there. But using a screen reader (preferably unsighted) to navigate your site with landmarks, headings, lists, and other modes will help make it clear when certain any of those elements and aria-roles are lacking. Beyond just making sure your site is WCAG X.X AAAA compliant, it will also help you understand if it actually offers a good experience for the user.
I'm curious: Are the aria-controls and aria-expanded properties enough to let a screen reader user know what's going on here? Would they know upon focusing on the heading with button that by "clicking" the button it expands more information about the heading? 🤔 Also, you had me yelling at the TV like a little kid about the "#" in aria-labelledby!!! So fun! 😂
When I tested it with the VoiceOver utility, it tells you that the button is attached to something that is "collapsed", which is maybe not the most verbose indication, but it IS there, and I didn't see any other guidelines on how to make it more verbose. But I'd be interested in hearing what you think! - Aurooba
In this episode, we were using React, so actually just removing it from the DOM completely: github.com/viewSourcePodcast/viewSource-blocks/blob/add/accordion-block-a11y/src/accordion/app.js In a recent talk at WP Accessibility Day, we did present an alternate version of the accordion, with the collapse script here: github.com/bacoords/a11y-day-accordion-block/blob/main/src/accordion-block/view.js The video of that talk has not been published as of this writing, but should eventually show up on TH-cam: th-cam.com/channels/es9XCUZd51CAigbBEGlfNg.htmlfeatured?view_as=subscriber
The 'viral' tital for the show: "All the javascript in the world won't save you!"
Really enjoyed the discussion on accessibility in general, and the technical sides you speak about in particular.
I think something missing from a lot of Accessibility videos is actually using the page/component with a screen reader. I think this is a crucial part of building accessible components. I often do integration accessibility tests for work and it becomes clear that developers never tried using the component with a screen reader.
Understanding how users that use screen readers use sites and components is really important. It's another level of learning that a lot of developers and designers don't want to deal with. Then they have an accessibility audit and get 200 issues noting that the site/component doesn't work well with a screen reader. Sometimes shrugging the issues off noting "I used semantic markup, aria-roles and it passes our required static analysis test".
Semantic markup, correct aria-roles and static-analysis tools get you a lot of the way there. But using a screen reader (preferably unsighted) to navigate your site with landmarks, headings, lists, and other modes will help make it clear when certain any of those elements and aria-roles are lacking. Beyond just making sure your site is WCAG X.X AAAA compliant, it will also help you understand if it actually offers a good experience for the user.
That's a great idea! We'll keep it in mind for another episode.
I'm curious: Are the aria-controls and aria-expanded properties enough to let a screen reader user know what's going on here? Would they know upon focusing on the heading with button that by "clicking" the button it expands more information about the heading? 🤔
Also, you had me yelling at the TV like a little kid about the "#" in aria-labelledby!!! So fun! 😂
ahahaha when Brian pointed out the hashtag to me I was like OMG HOW DID I MISS THAT. - Aurooba
When I tested it with the VoiceOver utility, it tells you that the button is attached to something that is "collapsed", which is maybe not the most verbose indication, but it IS there, and I didn't see any other guidelines on how to make it more verbose. But I'd be interested in hearing what you think! - Aurooba
I'm so glad I INTENTIONALLY put that INTENTIONAL error in my code. Did I mention it was INTENTIONAL and not a mistake? -B
Can you share the code for the collapse feature?
In this episode, we were using React, so actually just removing it from the DOM completely: github.com/viewSourcePodcast/viewSource-blocks/blob/add/accordion-block-a11y/src/accordion/app.js
In a recent talk at WP Accessibility Day, we did present an alternate version of the accordion, with the collapse script here: github.com/bacoords/a11y-day-accordion-block/blob/main/src/accordion-block/view.js The video of that talk has not been published as of this writing, but should eventually show up on TH-cam: th-cam.com/channels/es9XCUZd51CAigbBEGlfNg.htmlfeatured?view_as=subscriber
would be more more more and more usefull with a tab system