![\"The](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/01\/divide-corner-building.webp?resize=1200%2C600&ssl=1\")
Act 1<\/h3>\n\n\n\u201cI just don\u2019t know how developers don\u2019t think about accessibility.\u201d<\/p><\/blockquote>\n\n\n\n
Someone once said that to me. Let\u2019s stop and think about it for a minute. Maybe there\u2019s a perspective to be had.<\/p>\n\n\n\n
Think about how many things<\/em> you have to know as a developer to successfully build a website. In any given day, for any given job position in web development, there are the other details<\/em> of web development that come up<\/a>. Meaning, it\u2019s more than \u201cjust\u201d<\/em> knowing HTML, CSS, ARIA, and JavaScript. Developers will also learn other things over the course of their careers, based on what they need to do.<\/p>\n\n\n\nThis could be package management, workspaces, code generators, collaboration tools, asset loading, asset management, CDN optimizations, bundle optimizations, unit tests, integration tests, visual regression tests, browser integration tests, code reviews, linting, formatting, communication through examples, changelogs, documentation, semantic versioning, security, app deployment, package releases, rollbacks, incremental improvements, incremental testing, continuous deployments, merge management, user experience, user interaction design, typography scales, aspect ratios for responsive design, data management, and\u2026 well, the list could go on, but you get the idea.<\/p>\n\n\n\n
As a developer, I consider myself to be pretty gosh darn smart for knowing how to do most these things! Stop and consider this: if you think about how many people are in the world, and compare that to how many people in the world can build websites, it\u2019s proportionally a very small percentage. That\u2019s kind of\u2026 cool<\/em>. Incredible, even. On top of that, think about the last time you shipped code and how good that felt. \u201cI figured out a hard thing and made it work! Ahhhhh! I feel amazing!\u201d<\/p>\n\n\n\nThat kind of emotional high is pretty great, isn\u2019t it? It makes me smile just to think about it.<\/p>\n\n\n\n
Now, imagine that an accessibility subject-matter expert comes along and essentially tells you that not only are you not<\/em> particularly smart, but you have been doing things wrong<\/em> for a long time.<\/p>\n\n\n\nOuch. Suddenly you don\u2019t feel very good. Wrong? Me??<\/em> What??? Your adrenaline can even kick in and you start to feel defensive. Time to stick up for yourself\u2026 right? Time to dig those heels.<\/p>\n\n\n\nThe cognitive dissonance can even be really overwhelming. It feels bad to find out that not only are you not good at the thing you thought you were really good at doing, but you\u2019ve also been saying, \u201cScrew you, who cares about you anyway<\/em>,\u201d to a whole bunch of people who can\u2019t use the websites you\u2019ve helped build because you (accidentally or otherwise) ignored that they even existed, that you ignored users who needed something more than the cleverness you were delivering for all these years. Ow.<\/p>\n\n\n\nAll things considered, it is quite understandable to me that a developer would want to put their fingers in their ears and pretend that none<\/em> of this has happened at all<\/em>, that they are still very clever and awesome. That the one<\/em> \u201cexpert\u201d telling you that you did it wrong<\/em> is just one person. And one person is easy to ignore.<\/p>\n\n\n\n\u2014 end scene.<\/em><\/p>\n\n\nAct 2<\/h3>\n\n\n\u201cI feel like I don\u2019t matter at all.\u201d<\/p><\/blockquote>\n\n\n\n
This is a common refrain I hear from people who need assistive technology to use websites, but often find them unusable for any number of reasons<\/a>. Maybe they can\u2019t read the text because the website\u2019s design has ignored color contrast. Maybe there are nested interactive elements, so they can\u2019t even log in<\/em> to do things like pay a utility bill or buy essential items on their own. Maybe their favorite singer has finally set up an online shop but the user with assistive technology cannot even navigate the site because, while it might look interactive from a sighted-user\u2019s perspective, all the buttons are divs and are not interactive with a keyboard\u2026 at all.<\/p>\n\n\n\nThis frustration can boil over and spill out; the brunt of this frustration is often borne by the folks who are trying to deliver more inclusive products. The result is a negative feedback cycle; some tech folks opt out of listening because \u201cit\u2019s rude\u201d (and completely missing the irony of that statement). Other tech folks struggle with the emotional weight that so often accompanies working in accessibility-focused design and development. <\/p>\n\n\n\n
The thing is, these users have been ignored for so long that it can feel like they are screaming into a void. Isn\u2019t anyone listening? Doesn\u2019t anyone care?<\/em> It seems like the only way to even be acknowledged is to demand the treatment that the law affords them! Even then, they often feel ignored and forgotten. Are lawsuits the only recourse?<\/p>\n\n\n\nIt increasingly seems that being loud and militant is the only way to be heard, and even then it might be a long time before anything happens.<\/p>\n\n\n\n
\u2014 end scene.<\/em><\/p>\n\n\nAct 3<\/h3>\n\n\n\u201cI know it doesn\u2019t pass color contrast, but I feel like it\u2019s just so restrictive<\/strong> on my creativity as a designer. I don\u2019t like the way this looks<\/strong>, at all.\u201d<\/p><\/blockquote>\n\n\n\nI\u2019ve heard this a lot across the span of my career. To some, inclusive design is not the necessary guardrail to ensure that our websites can be used by all, but rather a dampener on their creative freedom.<\/p>\n\n\n\n
If you are a designer who thinks this way, please consider this: you\u2019re not designing for yourself. This is not like physical art; while your visual design can be artistic, it\u2019s still on the web. It\u2019s still for<\/em> the web. Web designers have a higher challenge\u2014their artistic vision needs to be usable by everyone. Challenge yourself to move the conversation into a different space: you just haven\u2019t found the right design yet<\/em>. It\u2019s a false choice to think that a design can either be beautiful or accessible; don\u2019t fall into that trap.<\/p>\n\n\n\n\u2014 end scene.<\/em><\/p>\n\n\nLet\u2019s re-frame the conversation<\/h3>\n\n\n
These are just three of the perspectives we could consider when it comes to digital accessibility.<\/p>\n\n\n\n
We could talk about the project manager that \u201cjust wants to ship features\u201d and says that \u201cwe can come back to accessibility later.\u201d We could talk about the developer who jokes that \u201cthey wouldn\u2019t use the internet if they were blind anyway,\u201d or the one that says they will only pay attention to accessibility \u201conce browsers make them do it.\u201d<\/p>\n\n\n\n
We could, but we don\u2019t really need to. We know how these these conversations go, because many of us have lived these experiences. The project never gets retrofitted. The company pays once to develop the product, then pays for an accessibility audit, then pays for the re-write after the audit shows that a retrofit is going to be more costly than building something new. We know the developer who insists they should only be forced to do something if the browser otherwise disallows it, and that they are unlikely to be convinced that the inclusive architecture of their code is not only beneficial, but necessary.<\/p>\n\n\n\n
So what should<\/em> we be talking about, then?<\/p>\n\n\n\nWe need to acknowledge that designers and developers need to be learning about accessibility much sooner in their careers. I think of it with this analogy: Imagine you\u2019ve learned a foreign language, but you only learned that language\u2019s slang. Your words are technically correct, but there are a lot of native speakers of that language who will never be able to understand you. JavaScript-first web developers are often technically correct from a JavaScript perspective, but they also frequently create solutions that leave out a whole lotta people in the end.<\/p>\n\n\n\n
How do we correct for this? I\u2019m going to be resolute here, as we all must be. We need to make sure that any documentation we produce includes accessible code samples. Designs must contain accessible annotations. Our conference talks must include accessibility. The cool fun toys we make to make our lives easier? They must be accessible, and there must be no excuse for anything less This becomes our new minimum-viable product for anything related to the web.<\/p>\n\n\n\n
But what about the code that already exists? What about the thousands of articles already written, talks already given, libraries already produced? How do we get past that? Even as I write this article for CSS-Tricks, I think about all of the articles I\u2019ve read and the disappointment I\u2019ve felt when I knew the end result was inaccessible. Or the really fun code-generating tools that don\u2019t produce accessible code. Or the popular CSS frameworks that fail to consider tab order or color contrast. Do I want all of those people to feel bad, or be punished somehow?<\/p>\n\n\n\n
Nope. Not even remotely. Nothing good comes from that kind of thinking. The good comes from the places we already know\u2014compassion and curiosity.<\/p>\n\n\n\n
We approach this with compassion and curiosity, because these are sustainable ways to improve. We will never improve if we wallow in the guilt of past actions, berating ourselves or others for ignoring accessibility for all these years. Frankly, we wouldn\u2019t get anything done if we had to somehow pay for past ignorant actions; because yes, we did ignore it. In many ways, we still do ignore it.<\/p>\n\n\n\n
Real examples: the Google Developer training teaches a lot of things, but it doesn\u2019t teach anything more than the super basic parts of accessibility<\/a>. JavaScript frameworks get so caught up in the cleverness and complexity of JavaScript that they completely forget that HTML already exists. Even then, accessibility can still take a back seat. Ember existed for about eight years before adding an accessibility-focused community group (even if they have made a lot of progress<\/a> since then). React had to have a completely different router solution<\/a> created. Vue hasn\u2019t even begun to publicly address accessibility in the core framework (although there are community efforts<\/a>). Accessibility engineers have been begging for inert<\/code><\/a> to be implemented in browsers natively, but it often is underfunded and de-prioritized.<\/p>\n\n\n\nBut we are technologists and artists, so our curiosity wins when we read interesting articles<\/a> about how the accessibility object model and how our code can be translated by operating systems and fed into assistive technology. That\u2019s pretty cool. After all, writing machine code so it can talk to another machine is probably more of what we imagined we\u2019d be doing, right?<\/p>\n\n\n\nThe thing is, we can only start to be compassionate toward other people once we are able to be compassionate toward ourselves. Sure, we messed up\u2014but we don\u2019t have to stay ignorant. Think about that time you debugged your code for hours and hours and it ended up being a typo or a missing semicolon. Do you still beat yourself up over that? No, you developed compassion through logical thinking. Think about the junior developer that started to be discouraged, and how you motivated them to keep trying and that we all have good days and bad. That\u2019s compassion.<\/p>\n\n\n\n
Here\u2019s the cool part: not only do we have the technology, we are literally<\/em> the ones that can fix it. We can get up and try to do better tomorrow. We can make some time to read about accessibility, and keep reading about it every day until we know it just as well as we do other things. It will be hard at first, just like the first time we tried\u2026 writing tests. Writing CSS. Working with that one API that is forever burned in our memory. But with repetition and practice, we got better. It got easier.<\/p>\n\n\n\nLogically, we know we can learn hard things; we have already learned hard things, time and time again. This is the life and the career we signed up for. This is what gets us out of bed every morning. We love challenges and we love figuring them out. We are totally here for this.<\/p>\n\n\n
What can we do? Here are some action steps.<\/h3>\n\n\n
Perhaps I have lost some readers by this point. But, if you\u2019ve gotten this far, maybe you\u2019re asking, \u201cMelanie, you\u2019ve convinced me, but what can I do right now<\/em>?\u201d I will give you two lists to empower you to take action by giving you a place to start.<\/p>\n\n\nCompassionately improve yourself:<\/h4>\n\n\n- Start following some folks with disabilities<\/strong> who are on social media with the goal of learning from their experiences. Listen to what they have to say. Don\u2019t argue with them. Don\u2019t tone police them. Listen to what<\/em> they are trying to tell you. Maybe it won\u2019t always come out in the way you\u2019d prefer, but listen anyway.<\/li>
- Retro-fit your knowledge.<\/strong> Try to start writing your next component with HTML first, then add functionality with JavaScript. Learn what you get for free<\/a> from HTML and the browser. Take some courses that are focused on accessibility for engineers. Invest in your own improvement for the sake of improving your craft.<\/li>
- Turn on a screen reader.<\/strong> Learn how it works. Figure out the settings\u2014how do you turn on a text-only version? How do you change the voice? How do you make it stop talking, or make it talk faster? How do you browse by headings? How do you get a list of links? What are the keyboard shortcuts<\/a>?<\/li><\/ol>\n\n\n\n
Bonus Challenge:<\/strong> Try your hand at building some accessibility-related tooling. Check out A11y Automation Tracker<\/a>, an open source project that intends to track what automation could exist, but just hasn\u2019t been created yet.<\/p>\n\n\nIncrementally improve your code<\/h4>\n\n\n
There are critical blockers that stop people from using your website. Don\u2019t stop and feel bad about them; propel yourself into action and make your code even better<\/strong> than it was before.<\/p>\n\n\n\nHere are some of the worst ones:<\/p>\n\n\n\n
- Nested interactive elements.<\/a> Like putting a button inside of a link. Or another button inside of a button.<\/li>
- Missing labels on input fields<\/a> (or non-associated labels)<\/li>
- Keyboard traps stop your users in their tracks. Learn what they are<\/a> and how to avoid them.<\/li>
- Are the images on your site important for users? Do they have the
alt<\/code> attribute<\/a> with a meaningful value?<\/li>- Are there empty links on your site? Did you use a link<\/a> when you should have used a button?<\/li><\/ol>\n\n\n\n
Suggestion:<\/strong> Read through the c<\/a>hecklist on The A11y Project<\/a>. It\u2019s by no means exhaustive, but it will get you started.<\/p>\n\n\n\nAnd you know what? A good place to start is exactly<\/em> where you are. A good time to start? Today.<\/p>\n\n\n\n
\n\n\n\nFeatured header photo by Scott Rodgerson<\/a> on Unsplash<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"You know that joke, \u201cTwo front-end developers walk into a bar and find they have nothing in common\u201d? It\u2019s funny, yet frustrating, because it\u2019s true. This article will present three different perspectives on accessibility in web design and development. Three perspectives that could help us bridge the great divide between users and designers\/developers. It might […]<\/p>\n","protected":false},"author":227124,"featured_media":360833,"comment_status":"open","ping_status":"closed","sticky":false,"template":"art-direction\/fancy-post.php","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"c2c_always_allow_admin_comments":false,"footnotes":"","jetpack_publicize_message":"Why Don't Developers Take Accessibility Seriously? by @melaniersumner","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[466],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/01\/scott-rodgerson-BwMcYuHI9OI-unsplash-scaled.jpg?fit=2560%2C1707&ssl=1","jetpack-related-posts":[{"id":19858,"url":"https:\/\/css-tricks.com\/the-accessibility-project\/","url_meta":{"origin":360811,"position":0},"title":"The Accessibility Project","date":"January 15, 2013","format":false,"excerpt":"Dave Rupert heads up a new project: For many web developers, accessibility is complex and somewhat difficult. [The Accessibility Project] understands that and we want to help to make web accessibility easier for front end developers to implement.","rel":"","context":"In "Link"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":298088,"url":"https:\/\/css-tricks.com\/growing-accessibility-conversations\/","url_meta":{"origin":360811,"position":1},"title":"Growing Accessibility Conversations","date":"November 22, 2019","format":false,"excerpt":"I started this year on a new path at Knowbility \u2014 to help people and organizations create accessible content and apps. But what was exciting and helped motivate me more were two things: WebAIM's Accessibility Analysis of One Million Page Homepages. With over 97% of sites having WCAG failure of\u2026","rel":"","context":"In "2019 End-of-Year Thoughts"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":301703,"url":"https:\/\/css-tricks.com\/debunking-the-myth-accessibility-and-react\/","url_meta":{"origin":360811,"position":2},"title":"Debunking the Myth: Accessibility and React","date":"January 15, 2020","format":false,"excerpt":"I find it notable when the blog of a major accessibility-focused company like Deque publishes an article called Debunking the Myth: Accessibility and React. Mark Steadman is essentially saying if a site has bad accessibility, it ain't React... it's you. The tools are there to achieve good accessibility. React didn't\u2026","rel":"","context":"In "Link"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/01\/Picture1-700x300-1.png?fit=700%2C300&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":335485,"url":"https:\/\/css-tricks.com\/weekly-platform-news-reduced-motion-cors-whitehouse-gov-popups-and-100vw\/","url_meta":{"origin":360811,"position":3},"title":"Weekly Platform News: Reduced Motion, CORS, WhiteHouse.gov, popups, and 100vw","date":"February 26, 2021","format":false,"excerpt":"In this week's roundup, we highlight a proposal for a new element, check the use of prefers-reduced-motion on award-winning sites, learn how to opt into cross-origin isolation, see how WhiteHouse.gov approaches accessibility, and warn the dangers of 100vh. Let's get into the news! The new HTML element is\u2026","rel":"","context":"In "Weekly Platform News"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/02\/wpn-20210226.jpg?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":377565,"url":"https:\/\/css-tricks.com\/accessible-forms-with-pseudo-classes\/","url_meta":{"origin":360811,"position":4},"title":"Accessible Forms with Pseudo Classes","date":"March 22, 2024","format":false,"excerpt":"Hey all you wonderful developers out there! In this post, I am going to take you through creating a simple contact form using semantic HTML and an awesome CSS pseudo class known as :focus-within. The :focus-within class allows for great control over focus and letting your user know this is\u2026","rel":"","context":"In "Article"","img":{"alt_text":"Web Form Accessibility with focus-within","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2024\/03\/focus-within-form-accessibility.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":294405,"url":"https:\/\/css-tricks.com\/weekly-platform-news-html-loading-attribute-the-main-aria-specifications-and-moving-from-iframe-to-shadow-dom\/","url_meta":{"origin":360811,"position":5},"title":"Weekly Platform News: HTML Loading Attribute, the Main ARIA Specifications, and Moving from iFrame to Shadow DOM","date":"August 15, 2019","format":false,"excerpt":"In this week's roundup of platform news, Chrome introduces a new attribute for loading, accessibility specifications for web developers, and the BBC moves visualizations to the Shadow DOM. Chrome ships the loading attribute The HTML loading attribute for lazy-loading images and iframes is now supported in Chrome. You can add\u2026","rel":"","context":"In "Weekly Platform News"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/08\/wpn-190814.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"featured_media_src_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/01\/scott-rodgerson-BwMcYuHI9OI-unsplash-scaled.jpg?fit=1024%2C683&ssl=1","_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/360811"}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/users\/227124"}],"replies":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/comments?post=360811"}],"version-history":[{"count":10,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/360811\/revisions"}],"predecessor-version":[{"id":362471,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/360811\/revisions\/362471"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media\/360833"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=360811"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/categories?post=360811"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/tags?post=360811"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\u201cI just don\u2019t know how developers don\u2019t think about accessibility.\u201d<\/p><\/blockquote>\n\n\n\n
Someone once said that to me. Let\u2019s stop and think about it for a minute. Maybe there\u2019s a perspective to be had.<\/p>\n\n\n\n
Think about how many things<\/em> you have to know as a developer to successfully build a website. In any given day, for any given job position in web development, there are the other details<\/em> of web development that come up<\/a>. Meaning, it\u2019s more than \u201cjust\u201d<\/em> knowing HTML, CSS, ARIA, and JavaScript. Developers will also learn other things over the course of their careers, based on what they need to do.<\/p>\n\n\n\n This could be package management, workspaces, code generators, collaboration tools, asset loading, asset management, CDN optimizations, bundle optimizations, unit tests, integration tests, visual regression tests, browser integration tests, code reviews, linting, formatting, communication through examples, changelogs, documentation, semantic versioning, security, app deployment, package releases, rollbacks, incremental improvements, incremental testing, continuous deployments, merge management, user experience, user interaction design, typography scales, aspect ratios for responsive design, data management, and\u2026 well, the list could go on, but you get the idea.<\/p>\n\n\n\n As a developer, I consider myself to be pretty gosh darn smart for knowing how to do most these things! Stop and consider this: if you think about how many people are in the world, and compare that to how many people in the world can build websites, it\u2019s proportionally a very small percentage. That\u2019s kind of\u2026 cool<\/em>. Incredible, even. On top of that, think about the last time you shipped code and how good that felt. \u201cI figured out a hard thing and made it work! Ahhhhh! I feel amazing!\u201d<\/p>\n\n\n\n That kind of emotional high is pretty great, isn\u2019t it? It makes me smile just to think about it.<\/p>\n\n\n\n Now, imagine that an accessibility subject-matter expert comes along and essentially tells you that not only are you not<\/em> particularly smart, but you have been doing things wrong<\/em> for a long time.<\/p>\n\n\n\n Ouch. Suddenly you don\u2019t feel very good. Wrong? Me??<\/em> What??? Your adrenaline can even kick in and you start to feel defensive. Time to stick up for yourself\u2026 right? Time to dig those heels.<\/p>\n\n\n\n The cognitive dissonance can even be really overwhelming. It feels bad to find out that not only are you not good at the thing you thought you were really good at doing, but you\u2019ve also been saying, \u201cScrew you, who cares about you anyway<\/em>,\u201d to a whole bunch of people who can\u2019t use the websites you\u2019ve helped build because you (accidentally or otherwise) ignored that they even existed, that you ignored users who needed something more than the cleverness you were delivering for all these years. Ow.<\/p>\n\n\n\n All things considered, it is quite understandable to me that a developer would want to put their fingers in their ears and pretend that none<\/em> of this has happened at all<\/em>, that they are still very clever and awesome. That the one<\/em> \u201cexpert\u201d telling you that you did it wrong<\/em> is just one person. And one person is easy to ignore.<\/p>\n\n\n\n \u2014 end scene.<\/em><\/p>\n\n\n \u201cI feel like I don\u2019t matter at all.\u201d<\/p><\/blockquote>\n\n\n\n This is a common refrain I hear from people who need assistive technology to use websites, but often find them unusable for any number of reasons<\/a>. Maybe they can\u2019t read the text because the website\u2019s design has ignored color contrast. Maybe there are nested interactive elements, so they can\u2019t even log in<\/em> to do things like pay a utility bill or buy essential items on their own. Maybe their favorite singer has finally set up an online shop but the user with assistive technology cannot even navigate the site because, while it might look interactive from a sighted-user\u2019s perspective, all the buttons are divs and are not interactive with a keyboard\u2026 at all.<\/p>\n\n\n\n This frustration can boil over and spill out; the brunt of this frustration is often borne by the folks who are trying to deliver more inclusive products. The result is a negative feedback cycle; some tech folks opt out of listening because \u201cit\u2019s rude\u201d (and completely missing the irony of that statement). Other tech folks struggle with the emotional weight that so often accompanies working in accessibility-focused design and development. <\/p>\n\n\n\n The thing is, these users have been ignored for so long that it can feel like they are screaming into a void. Isn\u2019t anyone listening? Doesn\u2019t anyone care?<\/em> It seems like the only way to even be acknowledged is to demand the treatment that the law affords them! Even then, they often feel ignored and forgotten. Are lawsuits the only recourse?<\/p>\n\n\n\n It increasingly seems that being loud and militant is the only way to be heard, and even then it might be a long time before anything happens.<\/p>\n\n\n\n \u2014 end scene.<\/em><\/p>\n\n\n \u201cI know it doesn\u2019t pass color contrast, but I feel like it\u2019s just so restrictive<\/strong> on my creativity as a designer. I don\u2019t like the way this looks<\/strong>, at all.\u201d<\/p><\/blockquote>\n\n\n\n I\u2019ve heard this a lot across the span of my career. To some, inclusive design is not the necessary guardrail to ensure that our websites can be used by all, but rather a dampener on their creative freedom.<\/p>\n\n\n\n If you are a designer who thinks this way, please consider this: you\u2019re not designing for yourself. This is not like physical art; while your visual design can be artistic, it\u2019s still on the web. It\u2019s still for<\/em> the web. Web designers have a higher challenge\u2014their artistic vision needs to be usable by everyone. Challenge yourself to move the conversation into a different space: you just haven\u2019t found the right design yet<\/em>. It\u2019s a false choice to think that a design can either be beautiful or accessible; don\u2019t fall into that trap.<\/p>\n\n\n\n \u2014 end scene.<\/em><\/p>\n\n\n These are just three of the perspectives we could consider when it comes to digital accessibility.<\/p>\n\n\n\n We could talk about the project manager that \u201cjust wants to ship features\u201d and says that \u201cwe can come back to accessibility later.\u201d We could talk about the developer who jokes that \u201cthey wouldn\u2019t use the internet if they were blind anyway,\u201d or the one that says they will only pay attention to accessibility \u201conce browsers make them do it.\u201d<\/p>\n\n\n\n We could, but we don\u2019t really need to. We know how these these conversations go, because many of us have lived these experiences. The project never gets retrofitted. The company pays once to develop the product, then pays for an accessibility audit, then pays for the re-write after the audit shows that a retrofit is going to be more costly than building something new. We know the developer who insists they should only be forced to do something if the browser otherwise disallows it, and that they are unlikely to be convinced that the inclusive architecture of their code is not only beneficial, but necessary.<\/p>\n\n\n\n So what should<\/em> we be talking about, then?<\/p>\n\n\n\n We need to acknowledge that designers and developers need to be learning about accessibility much sooner in their careers. I think of it with this analogy: Imagine you\u2019ve learned a foreign language, but you only learned that language\u2019s slang. Your words are technically correct, but there are a lot of native speakers of that language who will never be able to understand you. JavaScript-first web developers are often technically correct from a JavaScript perspective, but they also frequently create solutions that leave out a whole lotta people in the end.<\/p>\n\n\n\n How do we correct for this? I\u2019m going to be resolute here, as we all must be. We need to make sure that any documentation we produce includes accessible code samples. Designs must contain accessible annotations. Our conference talks must include accessibility. The cool fun toys we make to make our lives easier? They must be accessible, and there must be no excuse for anything less This becomes our new minimum-viable product for anything related to the web.<\/p>\n\n\n\n But what about the code that already exists? What about the thousands of articles already written, talks already given, libraries already produced? How do we get past that? Even as I write this article for CSS-Tricks, I think about all of the articles I\u2019ve read and the disappointment I\u2019ve felt when I knew the end result was inaccessible. Or the really fun code-generating tools that don\u2019t produce accessible code. Or the popular CSS frameworks that fail to consider tab order or color contrast. Do I want all of those people to feel bad, or be punished somehow?<\/p>\n\n\n\n Nope. Not even remotely. Nothing good comes from that kind of thinking. The good comes from the places we already know\u2014compassion and curiosity.<\/p>\n\n\n\n We approach this with compassion and curiosity, because these are sustainable ways to improve. We will never improve if we wallow in the guilt of past actions, berating ourselves or others for ignoring accessibility for all these years. Frankly, we wouldn\u2019t get anything done if we had to somehow pay for past ignorant actions; because yes, we did ignore it. In many ways, we still do ignore it.<\/p>\n\n\n\n Real examples: the Google Developer training teaches a lot of things, but it doesn\u2019t teach anything more than the super basic parts of accessibility<\/a>. JavaScript frameworks get so caught up in the cleverness and complexity of JavaScript that they completely forget that HTML already exists. Even then, accessibility can still take a back seat. Ember existed for about eight years before adding an accessibility-focused community group (even if they have made a lot of progress<\/a> since then). React had to have a completely different router solution<\/a> created. Vue hasn\u2019t even begun to publicly address accessibility in the core framework (although there are community efforts<\/a>). Accessibility engineers have been begging for But we are technologists and artists, so our curiosity wins when we read interesting articles<\/a> about how the accessibility object model and how our code can be translated by operating systems and fed into assistive technology. That\u2019s pretty cool. After all, writing machine code so it can talk to another machine is probably more of what we imagined we\u2019d be doing, right?<\/p>\n\n\n\n The thing is, we can only start to be compassionate toward other people once we are able to be compassionate toward ourselves. Sure, we messed up\u2014but we don\u2019t have to stay ignorant. Think about that time you debugged your code for hours and hours and it ended up being a typo or a missing semicolon. Do you still beat yourself up over that? No, you developed compassion through logical thinking. Think about the junior developer that started to be discouraged, and how you motivated them to keep trying and that we all have good days and bad. That\u2019s compassion.<\/p>\n\n\n\n Here\u2019s the cool part: not only do we have the technology, we are literally<\/em> the ones that can fix it. We can get up and try to do better tomorrow. We can make some time to read about accessibility, and keep reading about it every day until we know it just as well as we do other things. It will be hard at first, just like the first time we tried\u2026 writing tests. Writing CSS. Working with that one API that is forever burned in our memory. But with repetition and practice, we got better. It got easier.<\/p>\n\n\n\n Logically, we know we can learn hard things; we have already learned hard things, time and time again. This is the life and the career we signed up for. This is what gets us out of bed every morning. We love challenges and we love figuring them out. We are totally here for this.<\/p>\n\n\n Perhaps I have lost some readers by this point. But, if you\u2019ve gotten this far, maybe you\u2019re asking, \u201cMelanie, you\u2019ve convinced me, but what can I do right now<\/em>?\u201d I will give you two lists to empower you to take action by giving you a place to start.<\/p>\n\n\n Bonus Challenge:<\/strong> Try your hand at building some accessibility-related tooling. Check out A11y Automation Tracker<\/a>, an open source project that intends to track what automation could exist, but just hasn\u2019t been created yet.<\/p>\n\n\n There are critical blockers that stop people from using your website. Don\u2019t stop and feel bad about them; propel yourself into action and make your code even better<\/strong> than it was before.<\/p>\n\n\n\n Here are some of the worst ones:<\/p>\n\n\n\n Suggestion:<\/strong> Read through the c<\/a>hecklist on The A11y Project<\/a>. It\u2019s by no means exhaustive, but it will get you started.<\/p>\n\n\n\n And you know what? A good place to start is exactly<\/em> where you are. A good time to start? Today.<\/p>\n\n\n\n Featured header photo by Scott Rodgerson<\/a> on Unsplash<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" You know that joke, \u201cTwo front-end developers walk into a bar and find they have nothing in common\u201d? It\u2019s funny, yet frustrating, because it\u2019s true. This article will present three different perspectives on accessibility in web design and development. Three perspectives that could help us bridge the great divide between users and designers\/developers. It might […]<\/p>\n","protected":false},"author":227124,"featured_media":360833,"comment_status":"open","ping_status":"closed","sticky":false,"template":"art-direction\/fancy-post.php","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"c2c_always_allow_admin_comments":false,"footnotes":"","jetpack_publicize_message":"Why Don't Developers Take Accessibility Seriously? by @melaniersumner","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[466],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/01\/scott-rodgerson-BwMcYuHI9OI-unsplash-scaled.jpg?fit=2560%2C1707&ssl=1","jetpack-related-posts":[{"id":19858,"url":"https:\/\/css-tricks.com\/the-accessibility-project\/","url_meta":{"origin":360811,"position":0},"title":"The Accessibility Project","date":"January 15, 2013","format":false,"excerpt":"Dave Rupert heads up a new project: For many web developers, accessibility is complex and somewhat difficult. [The Accessibility Project] understands that and we want to help to make web accessibility easier for front end developers to implement.","rel":"","context":"In "Link"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":298088,"url":"https:\/\/css-tricks.com\/growing-accessibility-conversations\/","url_meta":{"origin":360811,"position":1},"title":"Growing Accessibility Conversations","date":"November 22, 2019","format":false,"excerpt":"I started this year on a new path at Knowbility \u2014 to help people and organizations create accessible content and apps. But what was exciting and helped motivate me more were two things: WebAIM's Accessibility Analysis of One Million Page Homepages. With over 97% of sites having WCAG failure of\u2026","rel":"","context":"In "2019 End-of-Year Thoughts"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":301703,"url":"https:\/\/css-tricks.com\/debunking-the-myth-accessibility-and-react\/","url_meta":{"origin":360811,"position":2},"title":"Debunking the Myth: Accessibility and React","date":"January 15, 2020","format":false,"excerpt":"I find it notable when the blog of a major accessibility-focused company like Deque publishes an article called Debunking the Myth: Accessibility and React. Mark Steadman is essentially saying if a site has bad accessibility, it ain't React... it's you. The tools are there to achieve good accessibility. React didn't\u2026","rel":"","context":"In "Link"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/01\/Picture1-700x300-1.png?fit=700%2C300&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":335485,"url":"https:\/\/css-tricks.com\/weekly-platform-news-reduced-motion-cors-whitehouse-gov-popups-and-100vw\/","url_meta":{"origin":360811,"position":3},"title":"Weekly Platform News: Reduced Motion, CORS, WhiteHouse.gov, popups, and 100vw","date":"February 26, 2021","format":false,"excerpt":"In this week's roundup, we highlight a proposal for a new Act 2<\/h3>\n\n\n
Act 3<\/h3>\n\n\n
Let\u2019s re-frame the conversation<\/h3>\n\n\n
inert<\/code><\/a> to be implemented in browsers natively, but it often is underfunded and de-prioritized.<\/p>\n\n\n\nWhat can we do? Here are some action steps.<\/h3>\n\n\n
Compassionately improve yourself:<\/h4>\n\n\n
Incrementally improve your code<\/h4>\n\n\n
alt<\/code> attribute<\/a> with a meaningful value?<\/li>
\n\n\n\n