Watched Update on Gutenberg accessibility audit by Joe Dolson from WP Campus

In late 2018, WPCampus released a
request for proposals
to conduct an accessibility audit of the WordPress Gutenberg editor. 
The vendor was selected,
and a fundraising goal of $31,200 was met. On April 29, 2019,
Tenon LLC
provided the final audit report to WPCampus. On May 1, 2019, 
WPCampus publicly shared the report documents.
What happened over the next year? Did any accessibility changes come to WordPress and the editor because of the audit?
Join Joe Dolson, a WordPress Accessibility team lead, as he shares outcomes of the WPCampus Gutenberg accessibility audit and the current state of progress
within WordPress accessibility.

This session was incredibly informative, and I’m glad there was a transcript. It made the session easier to consume and it also makes it easier to refer back to, at least for me.
Watched
I used Noter Live to generate these takeawayss, post them to Twitter as a thread, and generate the HTML with Microformats 2 to then post on my website. It’s really easy to use, very accessible, and is great for helping to ownw the content I create.

As with all Inclusive Design 24 talks, this one will include captions soon after the conference is over.

Marco Zehe:

Marco has worked for Mozilla since 2007, always in the accessibility field. He does quality assurance. He also worked for Freedom Scientific and helped with braille display dev in the early 2000’s.

Accessibility inspector is a new addition to Firefox dev toools, it’s a year old now.

Mozilla wanted to make sure devs could make their sites more accessible without having to download extras.

accessibility inspector allows devs to inspect the accessibility tree as presented to assistive technology users.

Latere versions introduce auditing features to highlight easily solvable problems. Helps devs solve problems and lets them see the problems go away.

Accessibility inspector is inside dev tools beside the HTML inspector. can be turned on in the context menu as well.

Unless you’re a screen reader user, turn on accessibility engine first.

Turn off when not using because it slows down the browser thanks to extra processing. If you turn off for one tab it turns it off for all.

Screen readers can’t accidentally turn off the accessibility engine.

Marco is demoing the tree views of the inspector.

Inspector is fully keyboard accessible.

If you have more than one tool bar on a page make sure that they are labeled and state their purposes. Marco is citing chapter and verse of WCAG.

Another cool visual feature: Accessibility highlight. Use the mouse to highlight and info bar shows complete color contrast for all colors and shows which ones pass.

Mozilla is trying to advance auditing with machine learning. Trying to determine whether or not machine learning can help. Finds patterns for fake elements.

Helps with div soup.

Mozilla wants feedback. Bugzilla, Twitter, public chat facilities.

The inspector can output its results as a json file.

Import resultant json into your tool of choice.

You can use the inspector as a blind/VI person. Sweet! Gonna go play with this now.

The info from the inspector is available on Linux as well, so you’ll get good enough results to not have to worry about switching to Mack/Windows screen readeres.

Marco attempts to avoid Chrome V. Firefox accessibility toools death match. Playing this well.

You can make dynamic changes in the dom inspector and they will be reflected in the accessibility inspector. Seems like this could be great for temporary hacks by screen readers.

Oh hey it’s @aardrian!

Mozilla’s accessibility team heavily collaborates with the other teams. Collaboration is facilitated. WordPress, please take note.

Thanks Marco, this talk was excellent, and I’m looking forward to playing with this.

Watched
Definitely some very useful information for developers. This stuff is core knowledge that needs to be grasped by developers before getting to the point of using tools or trying to test with assistive technology. I think it’s also useful information for testers as well as assistive technology users, if for no other reason than we are often tasked with doing advocacy work, and it’s to our advantage to try to make sure that the information we’re passing on is accurate so that accessibility problems can be fixed, and not just temporarily. Well, that’s the hope, anyway.
Watched
https://www.youtube.com/watch?v=eQg6pFg1XM0
I suspect that, as a general rule, open source treats the open web the same way that corporate software companies like Apple or Microsoft treat open source: It’s existence and that there are people to take care of it for you while you do the flashy stuff is taken for granted. As a result of this and many other things we, (at least in the US), have a situation where Facebook and Twitter are treated as the web, and then we’re all subjected to displays of incompetence, stupidity, and grifting that will eventually end up defining any possible laws we end up with when it comes to web things. I’d make grifting a link, but I refuse to link to anything related to Diamond and Silk, or any of the completely willfully ignorant comments by Ben Schapiro on this topic. Plus, there’s just way too much material. Fellow hackers, I think it’s time for our typical hands-off approach to anything but our code to end. We have to get involved, because if we don’t, it’s just going to get stupider as we go along, until the stupid gets boring and/or ineffective and it becomes actual malice, assuming we aren’t already to the malice bit. I’m holding out hope we’re still in the stupid portion though because that means we still have time to get off our asses and get involved.