What Publishers Need to Know About Web Accessibility

What Publishers Need to Know About Web Accessibility ![rw-book-cover](https://img.youtube.com/vi/QUb0tAS3D2g/maxresdefault.jpg) 🔗 **Source:** [What Publishers Need to Know About Web Accessibility](https://www.youtube.com/watch?v=QUb0tAS3D2g) > [!note]+ Document Notes > tags: #accessibility #wordpress #web-standards #assistive-technology #content-publishing #usability #screen-readers #wcag > author: Steve Burge > source: Publish Press > reference: https://www.youtube.com/watch?v=QUb0tAS3D2g > date created: 2024-12-19 14:30 > > # 🏷️ Title: What Publishers Need to Know About Web Accessibility >  ## 🧰 Action Inbox - [H1] Install accessibility testing plugin — start with automated scanning before manual testing #accessibility - [H2] Fix color contrast issues — ensure 4.5:1 minimum ratio for text readability #wcag - [H3] Review link text for clarity — replace "click here" with descriptive anchor text #screen-readers ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Equalized Digital Accessibility Checker](https://wordpress.org/plugins/accessibility-checker/) - [Overlay Fact Sheet](https://overlayfactsheet.com) ## 📝 Summary - Amber Hines from Equalized Digital explains how publishers can make their WordPress content accessible to people with disabilities - Automated testing tools are essential first steps, but shouldn't replace proper content creation practices - Common accessibility shortcuts like audio readers and overlay widgets often don't help the intended audience - Focus should be on semantic HTML, proper headings, color contrast, and clear link text rather than add-on features - Reading level matters significantly - content should be below 9th grade level for general audiences ## 📖 Main Content Publishers often ask about accessibility features like audio versions of articles or simplified text-only pages, but these approaches miss the fundamental issue. People who are blind already use screen readers to navigate computers, so adding an audio player doesn't specifically help them. Similarly, accessibility overlay widgets that add customization buttons often create more problems than they solve. The most effective approach involves automated testing to identify obvious issues, followed by manual testing. Color contrast failures, unclear link text ("click here" instead of descriptive links), and improper heading structure represent the most common problems. Screen reader users navigate by jumping between headings and links, so these elements must be semantically meaningful. Reading level assessment has become equally important. The average public reads below 9th grade level, and for international audiences where English isn't the primary language, simpler sentence structure improves comprehension significantly. This benefits both human readers and automated translation tools. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/QUb0tAS3D2g?t=0) — [H1] Introduction to WordPress accessibility - Key idea: Accessibility means helping as many people as possible access site content - Evidence: Focus on practical publisher questions about audio versions and streamlined sites #### ⏱️ [02:15](https://youtu.be/QUb0tAS3D2g?t=135) — [H2] Start with automated testing - Key idea: Automated testing identifies obvious problems before manual review - Evidence: "Start with automated testing and fix all of those really obvious problems first" #### ⏱️ [04:30](https://youtu.be/QUb0tAS3D2g?t=270) — [H3] On-server vs SaaS testing tools - Key idea: Server-based plugins avoid per-scan costs and data privacy issues - Evidence: "Our plugin is used on very large publisher websites. The largest of which is nasa.gov" #### ⏱️ [07:45](https://youtu.be/QUb0tAS3D2g?t=465) — [H2] Audio versions have limited accessibility value - Key idea: Blind users already have screen readers; audio players serve general usability - Evidence: "Blind people already have screen readers. They don't need features like that" #### ⏱️ [10:20](https://youtu.be/QUb0tAS3D2g?t=620) — [H1] Color contrast is fundamental - Key idea: Poor color contrast affects users with low vision and typical vision - Evidence: WordPress.org's blue on dark gray title "fails color contrast" #### ⏱️ [12:30](https://youtu.be/QUb0tAS3D2g?t=750) — [H3] Tooltip accessibility problems - Key idea: Helpful definitions can create barriers if not implemented properly - Evidence: Tool tips must be dismissible with escape key to meet WCAG standards #### ⏱️ [15:15](https://youtu.be/QUb0tAS3D2g?t=915) — [H2] Text-only versions can help but require caution - Key idea: Simplified versions may reduce noise but risk creating separate unequal experiences - Evidence: "Separate is not always considered equal" in accessibility lawsuits #### ⏱️ [18:45](https://youtu.be/QUb0tAS3D2g?t=1125) — [H1] Avoid accessibility overlays - Key idea: Widget overlays with customization buttons don't solve underlying problems - Evidence: "Most people with disabilities do not find those tools helpful" #### ⏱️ [21:30](https://youtu.be/QUb0tAS3D2g?t=1290) — [H2] Plugin demonstration begins - Key idea: Accessibility checker scans entire pages including headers, footers, sidebars - Evidence: Plugin flags "problems" (definite issues) and "needs review" (requires human assessment) #### ⏱️ [24:00](https://youtu.be/QUb0tAS3D2g?t=1440) — [H3] Fixing ambiguous anchor text - Key idea: Screen reader users navigate by listing all links on a page - Evidence: "Click here" links provide no context when listed separately #### ⏱️ [28:15](https://youtu.be/QUb0tAS3D2g?t=1695) — [H3] Image alt text considerations - Key idea: Empty alt text sometimes appropriate; decorative images shouldn't add noise - Evidence: Plugin flags empty alt text as "needs review" rather than automatic problem #### ⏱️ [32:45](https://youtu.be/QUb0tAS3D2g?t=1965) — [H2] Automated fixes for common issues - Key idea: Some problems can be resolved site-wide with single setting changes - Evidence: Link warnings can be added automatically across entire website #### ⏱️ [36:30](https://youtu.be/QUb0tAS3D2g?t=2190) — [H1] Reading level prominence - Key idea: General public reads below 9th grade level; content should match audience - Evidence: "Average reading level of the general public is a lot lower than many of us might realize" #### ⏱️ [40:20](https://youtu.be/QUb0tAS3D2g?t=2420) — [H2] International audience considerations - Key idea: Simpler language helps non-native speakers and automated translation - Evidence: "More than half your audience is probably going to be a non-native English speaker" #### ⏱️ [42:15](https://youtu.be/QUb0tAS3D2g?t=2535) — [H3] Theme and plugin selection importance - Key idea: Foundation accessibility comes from theme choice, not just content - Evidence: "A lot of accessibility issues can come from themes or plugins in WordPress" ## 📚 References - [WordPress Accessibility Meetup](https://equalizedigital.com/meetup) - [Accessibility Craft Podcast](https://accessibilitycraft.com) - [Equalized Digital Courses](https://equalizedigital.com/courses) - [Overlay Fact Sheet](https://overlayfactsheet.com) ## 🗣️ Paraphrase - Publishers should prioritize proper content creation over accessibility add-ons like audio players or overlay widgets - Automated testing tools help identify technical issues like color contrast and link problems across entire sites - Reading level matters enormously for accessibility, especially with international audiences where English isn't the primary language ## 📰 Newsletter **WordPress Accessibility: Start with the Fundamentals** Thinking about adding an audio player or accessibility widget to help disabled users? Hold that thought. Amber Hines from Equalized Digital shares why these common approaches often miss the mark. The real wins come from automated testing that catches color contrast issues and unclear link text, plus writing at or below 9th grade reading level. Screen reader users already have the tools they need - they just need your content to be structured properly with semantic HTML and descriptive headings. Check out the free Accessibility Checker plugin to identify issues across your entire site, including themes and plugins that might be creating barriers. Resources: [Learn WordPress](https://learn.wordpress.org/), [Accessibility Checker Plugin](https://wordpress.org/plugins/accessibility-checker/), [WordPress Accessibility Meetup](https://equalizedigital.com/meetup) ## ✅ Action Items #### WordPress - Core: Integrate reading level assessment into block editor alongside accessibility checks - Accessibility: Promote automated testing tools over overlay solutions in official documentation - Themes: Establish accessibility certification program for theme directory submissions - Plugins: Review and flag plugins that create common accessibility barriers - Documentation: Create publisher-specific accessibility guidelines with practical examples - Community: Support WordPress Accessibility Meetup with official resources and promotion #### OSPO - Policy & Governance: Establish accessibility requirements for open source project contributions - Developer Support: Include accessibility training in onboarding curricula for contributors - Community Engagement: Fund accessibility-focused sprints and developer education initiatives #### DevRel - Education: Create accessibility workshops targeted at content creators and publishers - Developer experience: Integrate accessibility testing into recommended development workflows - Developer marketing: Promote accessibility as performance and SEO benefit, not just compliance ## 🧪 Hypotheses - Publishers who implement automated accessibility testing first achieve better compliance outcomes than those who start with manual audits - Content written at 9th grade reading level or below increases engagement metrics for international WordPress audiences - WordPress sites using accessibility overlays receive more legal complaints than sites focusing on semantic HTML structure - Color contrast issues represent the most common accessibility barrier across WordPress publisher sites ### 📊 Methodology - Study design to test hypothesis 1: Compare accessibility audit scores before/after for sites implementing automated vs manual-first testing approaches - Data sources for hypothesis 2: Analyze reading level correlation with time-on-page and bounce rate metrics across multilingual WordPress sites - Experiments for hypothesis 3: Survey legal accessibility cases to identify patterns between overlay usage and lawsuit frequency ### ❓ Questions - How can WordPress core better surface accessibility issues during content creation without overwhelming editors? - What percentage of accessibility barriers stem from themes vs plugins vs content in typical publisher sites? - Should reading level assessment become a standard content quality metric alongside SEO scores? ### 🔮 Future Research - Develop machine learning models that can predict accessibility issues from content structure patterns - Investigate correlation between accessibility practices and site performance metrics across different publisher verticals - Study effectiveness of different accessibility training approaches for content teams ### 💡 Implications - Practice: Publishers should budget for accessibility testing tools and training rather than overlay solutions - Policy: WordPress hosting providers could differentiate by including accessibility scanning in their offerings - Education: Content management training programs need accessibility modules focused on semantic HTML and reading level - Funding: Grant programs should prioritize accessibility improvements in open source CMS development ### 🧠 Learning Styles Assessment Reading level estimate: 10th Grade (Flesch-Kincaid) #### 👀 Visual learners - Present: Plugin interface screenshots, color contrast examples, tooltip demonstrations - Improve: Add accessibility tree visualizations, before/after design comparisons #### 🔊 Aural learners - Present: Full podcast conversation with practical examples - Improve: Audio summaries of key plugin features and setup steps #### 🗣️ Verbal learners - Present: Clear definitions of screen readers, WCAG, semantic HTML - Improve: Accessibility terminology glossary, analogies for technical concepts #### 🧩 Kinesthetic learners - Present: Step-by-step plugin demonstration, hands-on accessibility fixes - Improve: Interactive accessibility audit checklist, sandbox testing environment #### 🧠 Logical learners - Present: Problem categorization (problems vs needs review), systematic fix approach - Improve: Decision trees for accessibility prioritization, metrics dashboards #### 🧑‍🤝‍🧑 Social learners - Present: WordPress Accessibility Meetup community, collaborative problem-solving - Improve: Peer review guidelines, accessibility mentorship programs #### 🧘‍♀️ Solitary learners - Present: Self-guided plugin exploration, individual content audits - Improve: Personal accessibility learning paths, self-assessment tools #### 🌿 Naturalistic learners - Present: Accessibility ecosystem overview, interconnected web standards - Improve: Systems thinking about digital inclusion, environmental metaphors ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Discussion of proper heading structure, link semantics, alt text - Improve: Add ARIA landmark examples, semantic HTML templates #### Keyboard navigation - Present: Focus on logical tab order, escape key functionality - Improve: Include keyboard navigation testing checklist #### Contrast and readability - Present: Specific color contrast examples, contrast checker tool demonstration - Improve: Add contrast ratio guidelines table, visual examples #### Text resizing and reflow - Present: Reading level assessment, simplified content discussion - Improve: Include responsive text sizing examples #### Media and captions - Present: Brief mention of video captions helping non-native speakers - Improve: Add comprehensive media accessibility guidelines #### Forms and interactions - Present: Link warning implementations, tooltip accessibility - Improve: Include form labeling best practices, error handling examples #### Standards reference - Content aligns with WCAG 2.1 AA guidelines for color contrast, keyboard access, and semantic structure ### 🌍 DEIB Assessment #### Cultural breadth - Present: Discussion of international audiences, non-native English speakers - Improve: Include examples from diverse publisher contexts globally #### Inclusive language - Present: Plain language emphasis, grade level considerations - Improve: Add inclusive terminology guidelines for accessibility discussions #### Neurodiversity support - Present: Reading level assessment, content structure emphasis - Improve: Include specific dyslexia considerations, cognitive load discussion #### Representation - Present: Diverse accessibility needs discussion beyond visual disabilities - Improve: Include examples of neurodivergent content creators, varied use cases #### Psychological safety - Present: Non-judgmental approach to accessibility learning - Improve: Add guidance for creating inclusive accessibility feedback processes ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from automated testing to manual review aligns with established accessibility methodology - Inductive strength: Examples from NASA.gov and large publishers support scalability claims - Causal reasoning: Connection between semantic HTML and screen reader navigation is well-established - Analogical strength: Comparison between accessibility overlays and AMP implementation effectively illustrates similar problems #### Fallacies - Appeal to authority: NASA.gov usage cited as evidence without performance metrics - False dilemma: Presents choice between proper implementation vs add-on tools without acknowledging hybrid approaches #### Tone of voice - Overall tone: Practical and educational, emphasizing solutions over problems with specific actionable examples ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on accusers present - Reverse victim/offender: No victim/offender reversals present - Emotional cues and rhetoric: Positive framing focuses on benefits rather than fear-based compliance messaging ## 🎯 Conclusion Effective accessibility for publishers starts with automated testing to identify technical issues, proper semantic HTML structure, and content written at appropriate reading levels. Add-on solutions like audio players or overlay widgets often don't help their intended audiences and can create additional barriers. The most impactful investments involve choosing accessible themes, training content teams on semantic markup, and implementing systematic testing workflows that catch problems before publication. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Automated accessibility testing identifies problems before manual review > [!quote] [What Publishers Need to Know About Web Accessibility](https://youtu.be/QUb0tAS3D2g) by [[Amber Hines]] --- ## Full Transcript [00:00] Hey and welcome to the Publish Press [00:01] podcast. I'm Steve Burge and in this [00:03] episode I'm talking with Amber Hines [00:05] from Equalized Digital. Now Amber is an [00:08] accessibility expert in WordPress. [00:11] Basically that means she helps as many [00:13] people as possible read the content on [00:15] your site. We get into some specific [00:18] questions I've had from publishers over [00:20] the last couple of years. For example, [00:22] should I have an audio version of my [00:24] content? Is that going to help more [00:26] people access my site? or should I have [00:28] a light version of the site where we [00:31] strip away all the design and simply [00:32] have the text? Amber's an expert on [00:35] these topics and so we talked to her [00:37] about how a publisher should best set up [00:40] their site to be as accessible as [00:42] possible for as many people as possible. [00:52] >> Hey Amber, welcome to the Publish Press [00:54] podcast. [00:55] >> Thanks for having me. I'm glad to be [00:56] here. Steve. [00:57] >> So, Amber, you work with a lot of [01:00] publishers, a lot of people that put out [01:02] a lot of content, and before we got on [01:05] the episode, we were taking a look at [01:08] WordPress.org, just as a as an example [01:11] of someone that puts out a lot of [01:13] content. Um, it could be similar to a [01:16] government website, a university [01:17] website, a newspaper website, a lot of [01:20] content, a few images. [01:23] How do you start by giving someone [01:26] advice to make content like this [01:28] accessible? What's the what are the big [01:31] picture things that people need to think [01:32] about? [01:33] >> There's a lot of things that makes it a [01:36] little bit hard for me to be like do [01:37] this one, two or three things, but so [01:39] what I would say high level to kind of I [01:42] guess promote my own thing a little bit, [01:44] not too much, but we have a plugin for [01:47] WordPress called accessibility checker. [01:50] Equalize digital accessibility checker. [01:51] There's a free version on WordPress.org. [01:54] Um, and that when it's installed on a [01:58] website, uh, gives you some really great [02:01] automated tests. We have more than 40, I [02:04] think almost 50 now that flag problems. [02:09] So, I would always say start with [02:12] automated testing and [02:15] fix all of those really obvious problems [02:18] first. And then from there, you want to [02:20] make sure that you're doing some manual [02:22] testing or maybe even bringing in people [02:24] with disabilities who use assistive [02:26] technology to test the website. [02:30] >> So, the automated testing is done with [02:33] an external tool. Um, I know we've had [02:36] people use our plugins who have sent us [02:38] a report and said, "You need to fix, you [02:41] know, X, Y, and Z." They've run some [02:44] automated testers and they've got a [02:46] spreadsheet of of issues they can send [02:49] to us. [02:51] >> Yeah. So, our plug-in is actually kind [02:54] of unique in that it's not an external [02:58] SASbased service that scans the website. [03:01] It runs directly on the WordPress [03:03] servers. Now, the huge benefit of this [03:06] is twofold. Number one, you don't have [03:09] to pay per scan or per page that you're [03:12] auditing like you have to do with a lot [03:14] of those SASbased services. So our [03:17] website is used on very large publish or [03:20] our plug-in is used on very large [03:22] publisher websites. The largest of which [03:23] is nasa.gov [03:25] which has millions of pieces of content [03:28] that have to be scanned for [03:30] accessibility. Um, and so it it can be [03:34] used to really help reduce cost on your [03:38] automated accessibility testing. Also, [03:40] it has that benefit because the scans [03:42] are on your server. All of your data [03:44] stays on your server, which I know a lot [03:46] of publishers get wary um particularly [03:49] if they are publishing member-based [03:51] content where only certain users are [03:53] supposed to have access. Um, that data [03:55] does stay on your own servers. It's not [03:57] being sent off somewhere via an API. [04:00] So, there's a bunch of SAS services out [04:02] there that I think often they work on a [04:05] not exactly a blackmail basis, but they [04:08] say, "Look at the cost of these [04:10] potential lawsuits. You might be you [04:13] might fall victim, too, if your site's [04:14] not accessible. Hey, you pay us $1,000 a [04:17] month. It seems like a bargain in [04:18] comparison." [04:19] >> Yeah. Fear. They use fear to sell their [04:22] crawler crawling. Um, we try, you know, [04:25] obviously there is some reality to that [04:28] fear and I acknowledge that, but I try [04:30] to be a little bit more positive in my [04:32] marketing and talk about the benefits of [04:34] accessibility. Um, because there is a [04:37] lot of overlap there, especially with [04:39] search engine optimization and ranking [04:42] and conversion optimization, getting [04:44] people to opt in or take the actions [04:46] that you want them to take on your [04:47] website. Uh, where, you know, [04:50] accessibility really can help with that. [04:52] Um, so we kind of try and differentiate [04:54] ourselves in that way. [04:55] >> Okay. So you've got some external SAS [04:57] services. You've got the option of a [05:00] plug-in running on WordPress.org. [05:03] If you take a look at um a a site like [05:08] um say WordPress.org, we have a post up [05:11] here. Are there any obvious things that [05:14] people can do to [05:16] make a post like this more accessible? [05:19] For example, I've seen some publishers [05:21] recently add audio versions of the [05:23] articles. And I think this can be done [05:26] almost at zero cost nowadays. You can [05:29] generate an automatic um Amazon an [05:32] Amazon voice to to read the post for [05:36] you. Is something like that helpful? So [05:39] I think having an audio player as long [05:42] as it is an accessible audio player that [05:45] uses correct buttons and correct [05:47] semantic HTML so that it can be played [05:50] by someone who relies on assistive [05:52] technology can be beneficial. I know. [05:55] Literally this morning I was emptying my [05:58] dishwasher and I listened to the audio [06:01] version of an article on NPR's website [06:05] >> because I wanted to consume the content, [06:08] but I was emptying my dishwasher. So, it [06:11] can be very beneficial to a lot of [06:14] users. But that said, I wouldn't think [06:17] that I need to add audio versions or the [06:21] ability to have it read to me to a [06:23] website to help blind people, for [06:25] example, because blind people in order [06:27] to even get on your website have to be [06:29] using a screen reader because that's the [06:30] way they use their computer, period. And [06:33] so, they could just tell their screen [06:34] reader to read them that article. So, [06:36] you're actually not going to be helping [06:38] someone who's blind uh with that [06:40] feature. I think people think, "Oh, do [06:42] that. It helps blind people." But blind [06:43] people already have screen readers. They [06:45] don't need features like that. [06:46] >> Okay. So there may be another small [06:47] group maybe people with say partial [06:50] vision. Um people who are doing the [06:53] laundry or doing the dishwasher. Um [06:57] >> but it's not a strict accessibility tool [07:00] and [07:00] >> no not particularly necessary. [07:02] >> It's not as much as we like to think it [07:03] is. I think it's just general usability [07:05] or allowing your content to reach more [07:08] people and it's a great practice to do. [07:11] Uh, it's just not necessarily like the [07:13] first thing I would say. Like if I I [07:16] look at that article that you pulled up [07:18] on WordPress.org, [07:20] the first thing that I saw immediately, [07:22] which I know our accessibility checker [07:24] plugin would flag, is that the title, [07:28] the make WordPress core title, uh, [07:32] that's a blue on a dark gray background. [07:36] I'm pretty sure that fails color [07:37] contrast. then our plugin would have [07:38] flagged that if they were using that, [07:40] which it's very difficult for a lot of [07:42] people with low vision or potentially [07:45] even typical vision to be able to see [07:47] that. So, I would look at that as [07:50] something to fix. Like maybe we need to [07:52] adjust these colors a little more to [07:54] make sure we have good color contrast. [07:57] There's a whole other can of worms on [07:59] these particular articles because they [08:01] use tool tips. If you were to hover over [08:03] beta for example, [08:06] um, we get a extra little popup that [08:11] shows up that explains beta. I haven't [08:14] tested this, but I would love to test [08:15] this and make sure does a screen reader [08:17] user have access to all this information [08:21] in the popup. Um, this does actually [08:23] fail WIKG because there's supposed to be [08:26] a feature on these where if you hover [08:29] over something and a tool tip pops up [08:32] that covers other content, you need to [08:34] be able to dismiss it without moving [08:36] your mouse. So, typically that means [08:37] hitting the escape key. And right now, [08:39] if you press the escape key, you'll [08:40] notice the pop-up does not go away. Um, [08:44] and and it's interesting these kind of [08:46] helpful things. A lot of publishers are [08:48] starting to add those to their content. [08:50] And they are maybe a nice way of [08:52] thinking, I'm going to make it more [08:53] accessible because I'm going to add a [08:54] definition for people who don't [08:55] understand what beta means or what [08:57] release candidate means in the context [09:00] of my article. Uh, but if they're not [09:03] implemented, well, then they can [09:04] actually cause more problems. So, I [09:06] often find myself going back and forth [09:09] with the um the people on our team who [09:12] design our plugins about the color [09:14] accessibility because [09:17] they often go for something that looks [09:19] really cool or [09:21] they're younger and they just have [09:23] better eyesight than I do. And so, um, [09:26] we will often use a tool such as such as [09:29] this contrast checker to make sure the [09:32] buttons on our plugins have clear [09:35] contrast of the text on the buttons. I [09:37] often find ourselves failing this in the [09:39] first version of the plug-in and having [09:40] to go back and and check to make sure [09:42] the color contrast is good enough. [09:45] Um I if you take a look at um a [09:50] publishers's website, does it help to [09:52] have a texton version or a light version [09:55] that strips away the header, the footer, [09:58] and all the extraneous content? [09:59] >> So this is something I think both the AP [10:03] News and maybe NPR's website do. They [10:06] have texton versions. I think it could [10:10] probably help assuming the texton [10:14] version has proper HTML semantics and [10:18] depending on how it's generated. Uh if [10:20] your images and icons and things like [10:23] that are [10:25] definitely decorative. Uh then if [10:28] they're not done properly, they could [10:30] add a lot of noise and just straight up [10:31] removing them could potentially be [10:33] helpful. Uh sometimes on the texton [10:36] versions we see publishers actually [10:38] don't put ads on them which is [10:40] interesting because I'm like maybe they [10:42] make less revenue when you read that [10:43] version but that also could be reducing [10:46] noise and getting people with [10:49] disabilities the content without having [10:51] to go past all of those ads. Um so I [10:56] think it could be beneficial. What you [10:58] have to be careful of is twofold. Uh, [11:01] one is that you don't really want to [11:04] create a totally alternative site if [11:06] you're removing any information that is [11:09] important or vital information. There [11:12] have been accessibility lawsuits in the [11:14] United States that have found that those [11:17] alternatives [11:19] separate is not always considered equal. [11:22] And so you need to make sure that you [11:24] are not removing important things. Um, [11:28] and then the other thing on that would [11:30] be you don't want to add an overhead of [11:34] management burden to your content team [11:36] where instead of having to edit [11:38] something on one page, they now have to [11:40] edit it on two. So, I would try to look [11:42] at ways, you know, are there WordPress [11:44] plugins that would help you generate [11:45] this version or would just take your [11:48] current website and remove everything if [11:52] they turn on this feature rather than [11:55] having two websites to maintain or which [11:59] I don't know potentially you could be [12:01] causing access or SEO issues for [12:04] yourself if your two websites are [12:06] fighting each other for ranking because [12:08] they have the same content. So, I I [12:10] would think carefully about how you do [12:12] it. I do think there are ways that it [12:13] could be beneficial. Yes. [12:16] >> Yeah. I remember the AMP era, the Google [12:18] AMP era of having a either a separate [12:22] version or a streamlined version of your [12:25] main site and that was just an enormous [12:28] pain. [12:29] >> That was that was [12:31] >> and they found that it hurt publishers [12:32] more than it helps them. [12:34] >> Yes. Okay. Okay. So, what I'm hearing [12:36] from you is [12:38] getting some of these extra tools such [12:41] as an audio reader or a streamline [12:45] version. Getting extra tools added to [12:47] your website is really not as helpful as [12:51] actually publishing your content [12:53] correctly the first time. [12:56] That [12:57] >> yes, [12:57] >> you you're better off spending your time [12:59] making sure that what's inside your [13:00] WordPress editor is done right. And [13:03] that's going to be more helpful than any [13:04] extra tools you can use. [13:07] >> For sure. Yeah. And I it's worth [13:09] mentioning there it's probably been an [13:13] increase in what's called accessibility [13:15] overlay use on publisher websites. And [13:18] people can typically see an [13:19] accessibility overlay because it adds a [13:21] little badge to the front left or right [13:24] bottom corner that looks like a person [13:26] in a wheelchair maybe or an [13:28] accessibility icon. And when you click [13:29] it, it opens up this whole set of tools [13:32] where it's like increase the contrast, [13:34] make the font size bigger, a lot of [13:36] different things. And that would fall [13:37] under that same category of things that [13:39] I would advise against doing. Um there's [13:42] a great website called the overlay fact [13:44] sheet that has a lot of information [13:46] about these tools, including user [13:50] um experiences with them. Most people [13:52] with disabilities do not find those [13:54] tools helpful. There have been actually [13:56] an increase in lawsuits against websites [13:59] that already use these tools. And so I [14:02] would definitely recommend if you're [14:03] considering using one or you already [14:05] have one to go read more on this overlay [14:08] fact sheet website that we have up on [14:09] the screen right now because it does [14:12] provide a lot of information about the [14:15] difficulties with these tools and [14:17] whether or not they actually work. Um, [14:19] there is actually a class action lawsuit [14:22] here in the United States against one of [14:23] these tools from business owners that [14:25] had it on their website and they got [14:27] sued anyway. Ouch. [14:28] >> Um, so it it didn't reduce legal risk [14:32] >> and it doesn't necessarily fix [14:34] accessibility problems. So, it is so [14:36] much better to just make sure you're [14:38] following best practices when you enter [14:40] the content on your website. [14:42] >> Okay, so no shortcuts. It's probably [14:44] going to be quicker and cheaper to [14:47] actually publish right the first time. [14:50] >> Correct. [14:51] >> So, the last couple of days before I [14:52] knew you were coming on the podcast, I [14:55] installed it, the accessibility checker [14:57] plugin, and have been playing around [15:00] with it. Um, let me bring it up. I have [15:04] a [15:05] uh a sample post with the accessibility [15:08] checker plugin. Um, we have the block [15:12] editor here and the accessibility [15:14] checker is up there in the top right [15:18] corner and can you talk me through it a [15:21] little bit? We've got a sidebar with [15:24] some some problems, some needs review [15:27] with the reading level. Can you talk me [15:29] through what I should be looking for? [15:31] >> Sure. So, accessibility checker, it's [15:35] good to know that it scans your entire [15:38] page. So, not just the content area, [15:41] which you're going to be able to edit [15:42] here. It will scan the header, the [15:45] footer, sidebars, any sort of other [15:48] areas that are created by the theme or [15:51] maybe by third party plugins that have [15:52] been added. So, it'll give you a full [15:54] accessibility audit of the whole page. [15:57] So, when you are looking at [15:59] accessibility checker, it's going to [16:02] tell you problems. These are things that [16:04] we can definitively tell with a code [16:08] review that this is something that is [16:10] bad for accessibility. And then we have [16:12] need review items. And these are items [16:15] that may be a problem or may not be a [16:17] problem, but a human has to assess them [16:20] and figure this out. Um, and basically [16:25] what you would do, I typically recommend [16:27] looking at problems first. So if you [16:29] wanted to, you can either click that [16:31] problems tile or you've already done [16:33] this. There's an accordion for [16:34] accessibility analysis and then in that [16:37] there's a problems tab. So we could look [16:39] at the very first issue here is [16:41] ambiguous anchor text. And when we [16:43] expand that there's one item and you [16:46] click the item title, it'll open a [16:47] modal. I frequently if you're not sure [16:50] where this click here sentence is, then [16:52] what I would do is click that view on [16:55] page link. And what that will do is open [16:59] your article in a new tab. [17:01] >> Ah, cover. [17:02] >> And uh I'm not sure if we're gonna be [17:05] able to see it. There we go. And it will [17:06] highlight it and help you find the issue [17:09] right on the post. So in this case, [17:12] we're saying, hey, you really need to [17:14] have a link that means something. Uh the [17:17] reason why is people who are blind, they [17:20] use a lot of different shortcuts in [17:22] their screen readers to navigate [17:24] websites. Just like you and I don't read [17:26] a whole every word on every page of [17:28] every website we visit. They don't want [17:30] to listen to every word of every page. [17:31] So they will do things like open up a [17:34] keyboard shortcut that reads them all [17:36] the links on a page and then they could [17:38] follow one. So obviously if a link says [17:41] click here, they don't know what here [17:44] goes to or why they would want to click [17:46] it. So my recommendation for the author [17:48] of this would be like let's say that was [17:50] a link over for B2 cafe log, right? [17:54] Instead of linking click here right [17:55] after that, we'd we'd fix our content to [17:58] actually link on the meaningful text, [18:01] right? And we could do that if you want [18:04] to look at it and show how it rescans. [18:08] >> Sure. uh take me through it. What would [18:10] I do next in order to fix this? [18:13] >> So go back to your tab with the editor [18:17] and that click here link should be in [18:18] your first paragraph. So we can close [18:20] out the issue modal and then we'll find [18:22] our click here and this is just an [18:26] example. So it's going to wordpress.org. [18:29] So you could extend this sentence [18:31] and you could just say click here to [18:33] visit WordPress.org or something like [18:35] that. You know, obviously if this were [18:38] longer, you'd want to uh make sure that [18:41] the sentence makes sense in your [18:44] paragraph, but since we're just doing an [18:45] example, we'll do that. [18:48] So now, if we if you save the post, [18:53] that will fix it on the front end of [18:55] your website and that triggers [18:57] accessibility checker to rescan. And [18:58] that problem has gone away. So we have [19:02] fixed that. [19:04] And on the front end, you can see now [19:07] that that problem is no longer there and [19:10] being flagged. [19:11] >> It looks like we've got more problems [19:13] highlighted. [19:15] >> Mhm. [19:17] >> You can also click on those buttons. So, [19:19] there's one on an image and click that. [19:21] And what it does is it tells you, oh, [19:23] your image has empty alternative text. [19:26] And this is on the front end it says [19:28] warning. We're in the middle of [19:29] transitioning our text. But on the back [19:31] end, um, it's going to say needs review. [19:35] So if we were to go back on the back end [19:38] and [19:40] you would see this under the needs [19:41] review tab in the accessibility [19:43] analysis, [19:44] image empty alternative text. So that's [19:47] where that issue is. Um, now the reason [19:50] why this needs review is sometimes it is [19:52] correct for images not to have [19:54] alternative text. In this case, I would [19:57] say we probably want to add alternative [19:59] text. And you could do that if you were [20:01] to go to the block sidebar. Um, there's [20:03] going to be a place for you to write [20:05] alternative text here describing the [20:08] image. You don't typically want to put [20:09] this is a photo of only because a screen [20:12] reader is going to you could do that, [20:15] but I'm I am pretty sure that our [20:18] plug-in would then warn you you've [20:19] written not good alternative text, so [20:22] you'd trade one issue for another one. [20:24] Um, but what is maybe worth looking at. [20:29] So you've saved it. You could go back to [20:31] the accessibility checker report now and [20:33] you should see that issue is gone. So [20:36] our needs review is only five and that's [20:38] no longer there. Um, [20:41] so that's kind of a high level on how [20:43] you use it. You could also do things [20:48] like um you can dismiss issues. So some [20:51] of these needs review depending upon [20:53] what they are. Um you could dismiss [20:57] them. Our link opens new windows tab [20:59] actually has an apply fix. So some [21:02] problems we have automated fixes for. [21:04] You could click apply fix under this [21:06] issue and this gives you the option of [21:09] doing two things for this particular one [21:11] is you could either stop all links from [21:14] opening new windows and toggle that on [21:16] and it will fix it across your entire [21:18] website or let's say you really want [21:21] that behavior then the solution is to [21:23] warn people. So, we could instead add a [21:26] warning when link opens a new window or [21:29] tab, and that will put an icon and a [21:33] screen reader alert that warns them. So, [21:36] they know that their back button will no [21:38] longer work once they click this link. [21:40] They'll have to close the tab to get [21:42] back. They can't use the back button in [21:43] the browser, which is why you want the [21:45] warning there so they know how to return [21:47] to the website. [21:48] >> I'll give that a little test. [21:51] >> Yeah. Did you turn on both or just one? [21:55] Uh, both. [21:56] >> Okay. So, they're going to cancel each [21:58] other out. [21:59] >> Oh, that's true. Okay. [22:00] >> So, if you if you want to see the [22:02] warning, then we'll have to turn off the [22:05] fix, which you are now going to find. [22:08] It's probably gone now. So, you'd have [22:10] to go to accessibility checker settings [22:11] and turn off the fix for blocking [22:16] links from opening in new tabs. So, [22:18] under accessibility checker settings, [22:20] there's a fixes tab up at the top. And [22:23] then if we scroll down, so you can see [22:25] we have a lot. Yeah, I'd uncheck the [22:26] block links and then hit save at the [22:28] very bottom. So these are all of our [22:29] automated fixes that we have introduced. [22:32] So now if we go back to your blog post [22:36] and you might need to refresh it without [22:38] the parameters on the URL or just view [22:40] it on the front end if you want to see [22:42] the warning. Uh do you know where that [22:44] link was? We didn't check first to see [22:45] where that link was that opened in a new [22:47] tab. [22:48] >> No, that's true. Okay. But um I should [22:50] now be getting a a warning if I go to [22:52] Yeah. So there there would be a visible [22:54] one. It won't show an accessibility [22:56] checker warning because you've solved [22:58] that problem. So that issue is now gone [23:00] from an accessibility checker [23:01] perspective. But if you scroll down, [23:03] maybe it's at the bottom in the footer. [23:05] We could look and see. There we go. See [23:07] that GPL? [23:08] >> Oh, there we go. [23:09] >> So what that fix did was it added the [23:12] icon that tells us for a cited person. [23:15] And then it also added a tool tip just [23:17] in case someone doesn't understand what [23:19] the icon means. So maybe somebody that [23:22] has learning disabilities or isn't an [23:25] expert on the web, like a older person, [23:27] they might not know what that icon [23:28] means. So that's why we have the tool [23:30] tip. And then for screen reader users, [23:32] it would also say opens a new window. So [23:35] that's what that fix did right there. [23:37] And and the cool thing about that fix is [23:40] because it does it across your entire [23:41] website is let's say you had that link [23:45] in your header or your footer and it was [23:47] on every single page. It would have [23:49] fixed that problem on every single page. [23:51] So you wouldn't see it in accessibility [23:52] checker reports anymore. [23:54] >> So the checker works just as much on the [23:56] front end of the site as it does in the [23:58] admin area. You can keep on clicking [24:00] through using the the modal in the in [24:04] the bottom right corner looking for more [24:05] issues trying to fix each issue in the [24:09] post. [24:10] >> Yep, that's correct. And I would say a [24:12] lot of content authors like this view [24:14] better than the sidebar view. The [24:16] sidebar view is a little bit more [24:18] technical. Um, and we're continuing to [24:21] work on um improving this front-end [24:24] view, but it does allow you to click [24:27] through and see all of your issues from [24:29] top to bottom in a front-end view. [24:32] >> Yeah, we've got some plugins that have a [24:34] lot of content kind of like [24:36] accessibility checker and it's not easy [24:39] to squeeze all that information into the [24:40] sidebar there. [24:42] >> It is really hard. So, we have in [24:45] classic editor, we have a metab box and [24:48] there is an ability to turn the metab [24:49] box on for the block editor, but this [24:54] sidebar, I think it it's nice because it [24:56] can be next to your content instead of [24:58] having to be down at the bottom like the [24:59] metab box. You don't have to scroll up [25:00] and down as much. Um, and and that is [25:03] why though we introduced the modals [25:05] because it was impossible to put [25:07] everything in the sidebar. So, some of [25:08] them do open in accessible modals as [25:11] well. So you have the technical issues [25:15] um all the way through the post but [25:17] almost on the same level as the [25:20] technical issues we have the reading [25:22] level of the post as well. Why have you [25:25] put that in such a prominent place in [25:27] the post? Why does it matter so much [25:29] what the reading level of your content [25:31] is? [25:32] >> So there's a lot of data actually that [25:35] show that the average reading level of [25:39] the general public is a lot lower than [25:42] many of us, you know, who are [25:44] professionals or professional [25:47] copywriters might realize. Uh it it is [25:51] recommended [25:52] as a best practice that if you're [25:54] publishing content for the general [25:56] public, which especially would come into [25:58] play if you are publishing just like [26:01] general marketing or any sort of content [26:04] for like a government website that's [26:06] targeting constituents in an area and [26:09] it's just general public. you don't know [26:11] who they are that your content needs to [26:13] be at a reading level that is below the [26:16] ninth grade equivalent in the US but [26:18] basically [26:20] not college level reading. Um and so we [26:24] have decided to make very prominent what [26:27] the reading level is so that people can [26:30] make sure they are creating content that [26:33] is easy to consume by most people. Um, [26:39] we use a flesh concaid grade level check [26:42] and that puts there. There is also a web [26:45] content accessibility guideline AAA [26:48] guideline which says if you're writing [26:50] content that is higher than this grade [26:52] level, you should provide a simplified [26:54] summary. And our plug-in does in the [26:57] sidebar have a space where you could [26:59] write a simplified summary and then it [27:02] would output it like above the post or [27:04] below. you can choose where you want it [27:06] to show and it will also grade level [27:09] check that for you to make sure that [27:11] you've hit the guideline. So if you want [27:13] to go above and beyond that can be [27:16] really helpful um to meet that AAA [27:19] success criterion. [27:20] >> We have a family member who is 80 plus [27:23] now and just told us the other day that [27:26] they've been dyslexic their whole life [27:28] and had just flagged it. [27:30] >> They've not been able to realize [27:32] initially that that's what they were. [27:34] Yeah. they kind of said in their 20s, in [27:37] their 30s, they came to that realization [27:40] and had just managed to find workarounds [27:43] to every issue that came up in their [27:45] life to avoid reading. Um, and I guess [27:48] the other way to think about it is [27:50] perhaps that we're talking for an [27:52] international audience often. And [27:56] for probably more than half of the [27:59] people reading our content, unless [28:01] you're like a local news publisher aimed [28:03] at a certain region, which is in an [28:05] English-speaking country, if you're [28:07] talking WordPress, if you're talking [28:09] technical stuff, more than half your [28:11] audience is probably going to be a [28:12] non-native English speaker. [28:13] >> And yeah, easier to read sentences are [28:16] definitely very helpful for them. I'll [28:19] say accessibility in general is very [28:21] helpful for uh non-native speakers. So [28:25] beyond the reading level, having that [28:28] good semantic HTML, making sure you have [28:31] headings that are used appropriately and [28:34] break up content makes it a lot easier [28:36] for people to understand different [28:38] sections of an article. Um, it also [28:41] makes it easier for automated [28:42] translation tools, uh, and videos as [28:46] well. Putting captions on videos, it [28:49] helps people who are deaf or heart of [28:51] hearing, but if someone's not a native [28:52] speaker, sometimes being able to see the [28:55] words at the same time that they hear [28:56] them can help them to better comprehend [28:59] what's being said in a video. [29:01] I hadn't thought about it from a AI [29:03] point of view that the more the more [29:06] convoluted your sentences are, the more [29:08] the more complex you write perhaps the [29:10] more open you are being to being [29:12] misunderstood even by an intelligent [29:14] machine. [29:16] >> Mhm. [29:17] >> Um [29:19] that's awesome. Um is there anything [29:21] else we're we're missing that we looked [29:25] at some of the automated tools that are [29:26] available? um adding an audio [29:30] transcription, uh adding a simplified [29:33] version of your site. Generally, that's [29:35] not a great idea. Your your best [29:37] approach is to have something that sits [29:39] on your website and pinpoints the [29:42] problems one by one that you can solve [29:44] them. Do you have any other advice for [29:47] someone that's publishing a lot of text [29:49] content, a um a publisher, a government [29:52] or university organization? Is there [29:55] anything else they should be thinking [29:56] about? So, I would say in general, you [29:58] really want to make sure that your theme [30:02] that you select is accessible. A lot of [30:05] accessibility issues can come from [30:07] themes or plugins in WordPress. So, [30:10] being very thoughtful about how you [30:12] build your website around your content [30:15] is key. Uh, I would spend a lot of time [30:17] looking at your navigation menus in [30:20] particular because that's one of the [30:21] most important ways that people are [30:23] going to be able to move around your [30:24] site. So doing that is important and it [30:27] does require some manual testing. So if [30:29] that's something that you're a developer [30:31] or you aren't an expert at, then I would [30:33] recommend bringing someone in. Um that [30:36] would be my my top recommendation is [30:39] making sure you do automated and manual [30:42] testing. I wouldn't just stop with the [30:43] automated. [30:45] So if people are interested in knowing [30:47] more about accessibility particularly in [30:49] the WordPress context, I know you guys [30:51] over at Equalized Digital publish and [30:54] have podcasts and webinars and are [30:57] really building quite a community around [30:59] this. [31:00] >> We are so we are the official organizer [31:04] of the WordPress accessibility meetup [31:07] which is not like a normal WordPress [31:09] meetup. It's not city based. It's all [31:11] online uh with Zoom. It has we actually [31:14] have live captioners who are coming. So [31:16] if you're deaf or heart of hearing, [31:17] there's human captioners that come. We [31:19] are the first Thursday of the month and [31:22] the third Tuesday of the month at 10:00 [31:26] a.m. US Central time or 5:00 p.m. C. And [31:32] um we if you go to equestual.com/meup, [31:37] you can get to this web page, you can [31:38] see upcoming events and register for [31:40] them totally free. We also post up [31:43] recordings from all of those and we've [31:46] been running this since 2020 or 2021. [31:50] So, we have hundreds of recorded [31:52] webinars from these meetups. Um, some of [31:55] which many of which are about an hour [31:57] and a half long. So, they're super [31:59] detailed and you can just search for a [32:01] specific topic. So, this is a great [32:03] learning opportunity. As um we mentioned [32:07] previously, we also have courses uh [32:10] which you can find on our website if you [32:12] go under learn and there's courses [32:14] available there. So we have uh two [32:17] online courses for screen readers, one [32:19] on voice over for Mac and the other on [32:21] NVDA for Windows. And I was talking [32:25] about manual testing. If you want to [32:26] learn how to manually test, this is [32:29] probably a great course for you. Um, and [32:32] then we also have one that's more [32:34] targeted to agencies or developers on [32:36] selling accessibility. Uh, so we have [32:38] those as well. And trying to think other [32:41] resources just in general. Yeah, you [32:43] mentioned our podcast. We It's kind of [32:45] fun. We talk about accessibility and [32:47] craft beverages. So if you're into that, [32:49] we always have a beverage for an episode [32:52] and it's a little bit like an [32:53] accessibility happy hour and you can [32:55] find that at accessibilitycraft.com. [32:59] >> Okay. So, this is the accessibility [33:00] craft podcast. [33:02] >> Yep. [33:03] >> And when you say craft, I guess there's [33:05] a pun in craft brewing as well. [33:08] >> Yeah, that's kind of my nerdy idea is [33:11] it's like the art or craft of making [33:14] accessible websites, but also craft [33:18] breweries. We do beer. We've done uh but [33:22] we also do non-alcoholic things and [33:23] we've done hard seltzers and sodas and [33:27] kind of if it's an artisal beverage then [33:29] we try it. We don't take ourselves too [33:32] seriously. I will say my partner Chris [33:35] he has a culinary degree and is probably [33:38] the most the closest we would get to [33:40] like a beverage expert. So he can always [33:42] do that. But sometimes we have also [33:44] tried things we just thought were [33:45] probably going to be really gross but [33:47] funny on the podcast. So, um, one of our [33:51] developers is from Scotland, so he came [33:54] on the end episode and we tried a [33:56] beverage called Iron Brew from Scotland, [34:00] >> which was kind of amusing. And we've [34:02] tried like dill pickle sour beer. So, we [34:07] have fun with it. Uh, and we also do try [34:09] some good things that are worth tasting [34:11] as well. We rate them and we talk about [34:13] accessibility while we drink. [34:16] >> Awesome. Um, well, thank you so much, [34:18] Amber. If um if people want to follow [34:20] you personally, where's the best place [34:22] to follow you? Where do you post? [34:24] >> Post most frequently on X or Twitter, [34:27] and you can find me there. Hey, [34:29] AmberHines. I'm also on LinkedIn as [34:32] well, and my last name is spelled H I N [34:34] Ds if you want to look me up. [34:37] >> Awesome. Thank you so much, Ember. [34:38] >> Thank you.  📄 **Full text:** ![[Full Document Contents/Articles/What Publishers Need to Know About Web Accessibility.md|What Publishers Need to Know About Web Accessibility by YouTube]] ## Highlights - picture things that people need to think about? >> There's a lot of things that makes it a little bit hard for me to be like do this one, two or three things, but so what I would say high level to kind of I guess promote my own thing a little bit, not too much, but we have a plugin for WordPress called accessibility checker. Equalize digital accessibility checker. There's a free version on WordPress.org. Um, and that when it's installed on a website, uh, gives you some really great ([View Highlight](https://read.readwise.io/read/01kqcqzsjnnd57wfjnfss84sa3)) - Tags: 👻 ai highlighted - WordPress editor is done right. And that's going to be more helpful than any extra tools you can use. >> For sure. Yeah. And I it's worth mentioning there it's probably been an increase in what's called accessibility overlay use on publisher websites. And people can typically see an accessibility overlay because it adds a little badge to the front left or right bottom corner that looks like a person in a wheelchair maybe or an accessibility icon. And when you click it, it opens up this whole set of tools ([View Highlight](https://read.readwise.io/read/01kqcqzskt8wnze4p0pz276adc)) - Tags: 👻 ai highlighted - >> and it doesn't necessarily fix accessibility problems. So, it is so much better to just make sure you're following best practices when you enter the content on your website. >> Okay, so no shortcuts. It's probably going to be quicker and cheaper to actually publish right the first time. >> Correct. >> So, the last couple of days before I knew you were coming on the podcast, I installed it, the accessibility checker plugin, and have been playing around with it. Um, let me bring it up. I have ([View Highlight](https://read.readwise.io/read/01kqcqzsmxkykhx8efydy3q0m6)) - Tags: 👻 ai highlighted - a uh a sample post with the accessibility checker plugin. Um, we have the block editor here and the accessibility checker is up there in the top right corner and can you talk me through it a little bit? We've got a sidebar with some some problems, some needs review with the reading level. Can you talk me through what I should be looking for? ([View Highlight](https://read.readwise.io/read/01kqcqzsq4s0qfreys98669eyd)) - Tags: 👻 ai highlighted - tell you problems. These are things that we can definitively tell with a code review that this is something that is bad for accessibility. And then we have need review items. And these are items that may be a problem or may not be a problem, but a human has to assess them and figure this out. Um, and basically what you would do, I typically recommend looking at problems first. So if you wanted to, you can either click that ([View Highlight](https://read.readwise.io/read/01kqcqzst0ftyxzb0pjc50q3cp)) - Tags: 👻 ai highlighted - >> Ah, cover. >> And uh I'm not sure if we're gonna be able to see it. There we go. And it will highlight it and help you find the issue right on the post. So in this case, we're saying, hey, you really need to have a link that means something. Uh the reason why is people who are blind, they use a lot of different shortcuts in their screen readers to navigate websites. Just like you and I don't read a whole every word on every page of every website we visit. They don't want ([View Highlight](https://read.readwise.io/read/01kqcqzsv9rbt58e7xr4h3x2pk)) - Tags: 👻 ai highlighted - make sure they are creating content that is easy to consume by most people. Um, we use a flesh concaid grade level check and that puts there. There is also a web content accessibility guideline AAA guideline which says if you're writing content that is higher than this grade level, you should provide a simplified summary. And our plug-in does in the sidebar have a space where you could write a simplified summary and then it ([View Highlight](https://read.readwise.io/read/01kqcqzsyem4sq38tg28gynd8y)) - Tags: 👻 ai highlighted