![Eric Eggert](/img/default-banner.jpg)
- 13
- 41 382
Eric Eggert
Germany
เข้าร่วมเมื่อ 25 พ.ค. 2006
Hi!
My name is Eric Eggert, an award winning web accessibility expert who writes and creates other content about all things on the intersection of accessibility and design.
Here, on TH-cam, I explain Web Accessibility in a way that is easy to understand for everyone.
From 2013-2020 I worked with the World Wide Web Consortium (W3C), the standards makers for the web, to improve the documentation around web accessibility. You can find a list of the articles and resources I worked on below. Since 2016, this work was done on behalf of the US non-profit Knowbility, donating 50% of my time in a Fellowship to W3C. The rest of the time I worked on assessments and trainings for Knowbility. Since April 2020 I lead the technical accessibility team at Knowbility.
My name is Eric Eggert, an award winning web accessibility expert who writes and creates other content about all things on the intersection of accessibility and design.
Here, on TH-cam, I explain Web Accessibility in a way that is easy to understand for everyone.
From 2013-2020 I worked with the World Wide Web Consortium (W3C), the standards makers for the web, to improve the documentation around web accessibility. You can find a list of the articles and resources I worked on below. Since 2016, this work was done on behalf of the US non-profit Knowbility, donating 50% of my time in a Fellowship to W3C. The rest of the time I worked on assessments and trainings for Knowbility. Since April 2020 I lead the technical accessibility team at Knowbility.
How UserWay (accessibility overlay) does not work
FLICKER WARNING! Some content in this video flickers rapidly while demonstrating functionality of the UserWay overlay. If you react negatively to flickering content, best skip the following sections:
11:55-12:04, 12:47-13:10, 13:36-13:43, 14:23-14:41
This is an unedited rundown of me looking at a website promoted by UserWay.
This video is supported by my supporters: yatil.net/support
11:55-12:04, 12:47-13:10, 13:36-13:43, 14:23-14:41
This is an unedited rundown of me looking at a website promoted by UserWay.
This video is supported by my supporters: yatil.net/support
มุมมอง: 592
วีดีโอ
Figuring out WCAG Focus Appearance… Maybe?!
มุมมอง 230ปีที่แล้ว
This is a VERY IMPROVISED attempt to see if we can figure out, if an example conforms to the Focus Appearance Success Criterion or not. I think it does. Try it for yourself: www.w3.org/TR/WCAG22/#focus-appearance
Web Accessibility is broken. It’s time to fix it. #GAAD
มุมมอง 9502 ปีที่แล้ว
The web is still an accessibility wasteland. It must not be one. However, systematic issues plague progress that would enable millions of disabled people to properly participate as netizens. If we want the web to be a better, more accessible place, we have to align the easy, cost-effective decision with the correct, accessible decision. As long as our guidance is complicated, our tools hard to ...
Alles Gute zum 10. Global Accessibility Awareness Day! (Deutsch) #gaad
มุมมอง 1053 ปีที่แล้ว
Transcript: Hallo, mein Name ist Eric Eggert und ich bin Mitgründer von Outline Consulting und Director of Accessibility Services bei Knowbility. Ich wünsche Ihnen allen einen schönen 10. Global Accessibility Awareness Day, kurz GAAD oder G - A - A - D! Am dritten Donnerstag im Mai jeden Jahres regt der Global Accessibility Awareness Day an, über digitalen Zugang, Inklusion und die mehr als ein...
Three quick tips to achieve your 2021 accessibility goals
มุมมอง 5933 ปีที่แล้ว
In this video I introduce setting the language of the content, giving interactive elements accessible names, and using landmark regions. Transcript: yatil.net/videos/7-three-quick-tips/ Patreon: patreon.com/yatil Twitter: yatil Microblog: micro.yatil.net
How are Web Standards born? (& Happy Blue Beanie Day!)
มุมมอง 3673 ปีที่แล้ว
Happy Blue Beanie Day! Transcript: yatil.net/videos/6-web-standards/ * Technical Reports Page: www.w3.org/TR * Working Groups: www.w3.org/groups/wg/
5 False Claims 1-Line "AI" Accessibility Script Vendors Make
มุมมอง 1.2K3 ปีที่แล้ว
Transcript: yatil.net/videos/5-five-false-claims/ Support this channel at patreon.com/yatil • Follow me at yatil A rant about 1-line "accessibility" scripts. * Selecting Evaluation Tools: www.w3.org/WAI/test-evaluate/tools/selecting/#cannot * 11,000 ADA Title III lawsuits in 2019: www.adatitleiii.com/2020/02/2019-was-another-record-breaking-year-for-federal-ada-title-iii-lawsuits/ *...
Almost 50% Got This #a11y Question Wrong! - WCAG Explained
มุมมอง 1.1K3 ปีที่แล้ว
Transcript: yatil.net/videos/50-percent-got-this-accessibility-question-wrong/ Support this channel at patreon.com/yatil • Follow me at yatil I asked my followers a question and you would not believe how undecided they were. * The Tweet: yatil/status/1311348622366257153 * HTML Accessibility API Mappings: www.w3.org/TR/html-aam-1.0/ * WAI-ARIA Accessible Rich Internet App...
How ARIA fits in the Layers of Accessibility Technologies - Web Tech Explained
มุมมอง 9363 ปีที่แล้ว
Transcript: yatil.net/videos/how-aria-fits-in-the-layers-of-accessibility-technologies/ Support this channel at patreon.com/yatil • Follow me at yatil There are multiple layers of accessibility technology. This video gives a super broad overview on what they are and how they interact. * HTML Specification: html.spec.whatwg.org/multipage/ * WAI-ARIA Accessible Rich Internet Applicati...
Why is the Tab Key SO Important for Web Accessibility? - Keyboard Interaction Explained
มุมมอง 3.4K3 ปีที่แล้ว
Transcript: yatil.net/videos/why-is-the-tab-key-so-important-for-web-accessibility/ Support this channel at patreon.com/yatil • Follow me at yatil Web Content Accessibility Guidelines (WCAG) Specification: www.w3.org/TR/WCAG21/
A WCAG Overview - Web Content Accessibility Guidelines (WCAG) 2.1 and 2.0 Explained
มุมมอง 31K3 ปีที่แล้ว
Transcript: yatil.net/videos/a-wcag-overview/ Support this channel at patreon.com/yatil • Follow me at yatil Web Content Accessibility Guidelines (WCAG) Specification: www.w3.org/TR/WCAG21/
Keep It Simple - Barrierefreies Design-Thinking @ Webkongress Erlangen 2018
มุมมอง 1884 ปีที่แล้ว
ARIA. HTML. CSS. Animationen. Interaktionen. Das Web 2018 ist überwältigend komplex. In diesem Vortrag zeigt Eric Eggert wie Sie sich barrierefreie Designprinzipien zunutze machen können, um barrierefreie Projekte besser und vor allem effektiver zu planen, kommunizieren und auszuführen. Lassen Sie teure Barrierefreiheitstests und das daraus resultierende Refactoring hinter sich. Barrierefreihei...
Thank You
Great session, thanks for the walkthrough
Clearly explained. Thanks!
Thank youuu your breakdown just helped untangle all of the information overload in my brain.
Thanks! You helped me a lot with your Video 💪
Thanks Eric
I just subscribed, as learning more about accessibility and best practices is something I really want to incorporate through my whole front end dev career (pretty new to the tech scene) but I think its easier to build good habits than it is to overwright bad ones. Great video :)
Skip to 5:30 for the start (watching replay)
Great videos about accessibly.
Really cool talk! To add to your points about the authoring experience, I remember at my previous company developers would often complain about how buggy screen readers are. I'm sure in reality the issues are a mix of poor markup, browser bugs, and legitimate screen reader bugs. But regardless of the cause, it seems like a very frustrating experience to develop an accessible (non-trivial) web application if you don't have indepth knowledge of the field. Another thing that I find catches people off guard - rules in the accessibility specs (or not in the spec at all) that try to account for author errors. For example, people wondering why their <table> element is being exposed as a LayoutTable in the AX tree rather than being exposed a "real" table. Or people wondering why presentational semantics for their elements aren't respected. The latter is at least in the spec, but it's definitely buried.
The good news is that the CR candidate is now live
Hi! New subscriber here. Thanks for going over this. Helps a lot.
Good efforts
Good presentation if you have time please make more videos on how to find out defects
Thank you, I will see how to do that well. It’s certainly on my list of topics. 🙂
WCAG 2.1 guidelines you can try sir for findout defects
can you increase the sound a bit
Thanks for watching. That’s unfortunately not possible retroactively, I’ll try to increase the volume for new videos.
please make video about interview questions on accessibility testing
The ARIA current element is so true, I wish we had this directly in HTML too. Really interesting talk Eric :)
Thank you!
Great content! Thank you very much!
Thank you Eric!
Thanks very much. your video is quite thorough and explicit. it gives enough details and examples to facilitate understanding.
make a video about web "Decorative Images" step by step, it will help us , thank you
Thanks for the idea! I have put it on the list of topics.
thank you so much Eric!
I would like to point out that the lightning around 12:20 was unpredictable and therefore this video does not follow WCAG 😂
Thanks for all the content you put out Eric, it's been super helpful as I sink further into this topic.
Really great video, thank you so much.
Cortex t-shirt 😎
On our Jira board we have a custom field containing all the WCAG 2.1 success criteria, plus three additional entries: "None" (the default), "Triage" and "No SC". The latter is used in cases like this, or in cases where there is a significant UX problem for users with disabilities. However, to play devil's advocate, I would down-prioritise an issue like this, since it has zero impact on users, and even though the aria is misused, it does not fail any SC. One more point - when looking at an small issue like this it's easy enough to say "this is a trivial thing to fix", but in my experience, these kinds of issues are often created by misconfigured code generators, automated deployments and other scripts, rather than manual markup. It can sometimes be far from trivial to change a templating engine, or code generator, which has been tested and signed-off as working, even if the desired change is small. This is especially true when the org has political, infosec-related, technical or even legal constraints in place to reduce 'tweaking' of production code. These are not excuses, they are just the reality for larger scale deployments in certain sectors. We've had Language of Page issues that go unfixed for months because our content loads inside someone else's . It's trivial to add a language code to a static HTML page you made yourself. It's quite a different matter to run the gauntlet of corporate bureaucraciy *just to get permission* to tweak something that is built and maintained by another team, or (in some cases) another firm.
Great presentation! Always good to refresh my knowledge. Thanks for sharing! 👍
Very nice. I like the German accent.
Thanks! 😃
Thank you for the wonderful video. You describe it very well and made it easy to understand
I'm watching this video 1.5 hour before my IAAP WAS Exam starts. Thank you for providing this quick, straight to the point video.
Thanks and good luck! Fingers crossed!
did you ever pass and get an accessibility job?
@@SuperLADM I didn't get an accessibility job specifically. I work as a developer and wanted to extend my knowledge and skills. I already work for a company who makes software for researchers and I wanted to make our product accessible :) Good luck friend, I hope you will succeed and have as much fun with it as I.
I could get some of it too! :)
I know for a fact that your German is better than my French!
@@yatil I love how your "hallo" sounds exactly like my "allo" (hello) - and means the same thing!
I understood ALMOST the whole thing 🥰
Was happy to see a new episode, but then saw the title :(
Sorry, I hope to have a new episode eventually. The first months of 2021 have been a wild ride. And I’ll move house in August, with space for dedicated video shooting. So my hope is that I’ll get back into it much more then.
Is web accessibility in demand in current market
Yes, very much so!
Thanks Eric. I've been trying to get a handle on 'Time-based media' and what that it's exact definition is and you put it succinctly. Many thanks.
The lightning was a hilarious touch! Great content this was helpful, thank you!!
Thank you very much!
my goal is to learn more about accessibilty, for example about aria- attrihutes. and i'm planning to learn from that channel
Thanks Eric for the video... Really appreciate your effort.
Thank you, Renjith!
Super Arbeit wie immer👍🏻
I am Pramit, the Founder of Louie Voice Control. As a Visually Impaired, I always felt the need for an app that will allow user to control favorite apps & phone with just voice commands. Thus Louie was born. See Louie in Action & please share your feedback. rb.gy/dfahp1 As I get more and more good feedback, it encourages my team and me work harder on enhancing the app. Help me create more awareness by spreading the word.
Thank you, captions! I HEARD YOU SAY IE! 🤣 I'd never thought I'd be wrestling with browser inconsistency again ... they don't all treat WebVTT formatting of captions the same. So, it doesn't behave the way you expect it to. Oy.
Looks like we need another WASP then! 😉
@@yatil HA! This is the ONLY way I can ever be a WaSP!
good introducgory video. you could add some examples, snippets of code or something to make video more interesting. waiting for video about 2.2!
Hi Lao! Thanks for your comment and suggestion! I’d like to keep the first videos a bit more general so that I can refer back from more hands-on videos later on.
2:01 Does Twitter fail 2.1.4? For example, pressing the N key opens the “New tweet” dialog.
Yes, that is a clear fail. They should have an option to deactivate that behavior but I have not been able to do so.
Love this video, and I look forward to more. I'm curious-do you know/are you able to tell us why a developer thought it made sense to apply aria-level in the first place? When I see broken ARIA I can usually guess what the developer's thought process was behind it, but in this case I'm at a loss.
Thanks for your lovely comment! I really don’t know. I guess it was copied from another example, maybe a tree view? I don’t think there was much active thinking behind it, especially as it was an outlier even in that project.
Another terrific video! You are getting some good comments over on the accessibility subreddit as well.
Thanks again, Jayne!
I'm not sure I follow the purpose of the video. I suppose if you want to nit-pick and see if the example exactly fails according to the specific wording of the success critieria, then one might say it's not a WCAG failure. The code fails the Nu Html Checker because of the invalid attribute, but as you said, an invalid attribute isn't in the list of four parsing errors. It probably should be (perhaps 4.1.1 should be updated to include that addition). But I don't know any accessibility expert that would *not* report this as a failure, and as @dennis said, it should be fixed. So back to my original comment, why is it important to have a video to show something people should never do and then justify that it's not a WCAG failure? That would seem to do the accessibility community a disservice.
Fair comment. And yes, I have argued that 4.1.1 should probably work more widely. On the other hand, it would have prevented us to use ARIA with HTML4 as that did not validate back in the day. I don't know how other people work, but sometimes you get explicit asks for WCAG conformance, especially in the context of lawsuits. I have also seen people push back on issues like this. Last but not least, if issues (like this) are inconsequential, they can prevent bigger issues from being addressed. Some people even might react negatively and get a bad impression of implementing accessibility when WCAG is used to argue for issues that have no actual impact. Also, I expect accessibility experts to read and interpret WCAG correctly. Report it as a bug, report it as a QA problem, but you cannot report it as a WCAG failure.
when there's a legal dimension, it can matter if something is ugly/broken code that has or hasn't got accessibility repercussions, and whether or not it hard fails WCAG or not. if it's the difference between "yeah, it's borked, but doesn't normatively fail" and "yes, you will get sued for this", it's worth being a bit more specific when something does or doesn't hard fail. and as eric says, nitpicking tiny bullshit like this helps nobody if it detracts from fixing issues that actually matter (i spent far too many hours with clients who obsessed about an absolutely trivial issue and getting that perfect, while the actual site/process at the macro level was completely broken. they latched onto the seemingly technically easy thing and ignored the far more fundamental "your entire site can't be used with keyboard/doesn't announce anything for AT users/something of similar critical importance)
Was about to say exactly the same as @Patrick Lauke here-an issue like this, while incorrect, is unlikely to impact a user in any way. Thus while it should be fixed, it should be lower priority than something that actually impedes a user. If it's deemed a WCAG failure then it immediately shoots up the priority list due to legal requirements, regardless of the actual impact on the user.
@@unomad112 and there's also the danger that if a client comes to you to do an audit because there's a legal dimension (they're getting sued or whatever), and you as an auditor flag something as a WCAG *fail* ... and it then later transpires that "oh, well, technically it's not a hard fail, but it's something you need to fix anyway", this immediately casts doubt in the client's mind on any other *fail*s that you told them about. And it can get even trickier if there are two or more auditors involved - one of them fails this, one of them passes but with note to fix ... leaves the client wondering why findings differ, and again then opens up a whole can of worms where clients need to be told that yes, some WCAG stuff is a bit subjective...which again can harm the client confidence. Anyway, it's all the stuff I rant about in th-cam.com/video/I0tghv881ac/w-d-xo.html so i'll stop here before reiterating my whole talk :)
A good WCAG analysis, but it doesn't matter if it passes or fails; the code is totally wrong and should be fixed.
I do not disagree :-)
Awesome explanation Eric. Thank you so much.
Thanks Bruno!
Great presentation. I appreciate how you broke down the guidelines in a very easy to understand way.
Thank you!