Brian Hogan

It's official: WCAG in Plain English is now complete. All 87 success criteria from WCAG 2.0, 2.1, and 2.2, including Levels A, AA, and AAA are now written in plain language and available for free. When we started this project, we had a simple goal: make WCAG actually approachable for newcomers. The official guidelines are dense, technical, and honestly intimidating for most people trying to build accessible websites. So we created plain-language introductions to help people get started. • Clear explanations of what each criterion means. • Real-world examples and practical guidance. • Organized by role, disability, theme, and compliance level. • Links to official WCAG documentation throughout. • No jargon, no confusion, just useful information. This has been a labor of love spanning 3+ years and 500+ hours from our team. We wanted to remove one of the biggest barriers to web accessibility: understanding what you're supposed to do in the first place. This isn't meant to replace the official WCAG documentation - it's designed to help you understand it and know where to start. Accessibility shouldn't require a decoder ring. Accessibility should be approachable, not intimidating. The resource is free, always will be, and built for anyone who wants to make the web more inclusive. Whether you're just getting started or you've been doing this for years, we hope it makes your work a little easier. Check it out: https://lnkd.in/ggHqn-MD #Accessibility #WCAG

2,140

169 Comments

Shared mailboxes don’t require sign-in, so why allow it? If you're still allowing shared mailboxes to sign in like regular users, sooner or later, suspicious activity may occur.🛑 They aren’t meant for interactive sign-ins, and leaving them open invites risk. Blocking sign-in is a must, but doing it manually is a hassle. I use a handy PowerShell script that not only blocks sign-in but also checks sign-in status across mailbox types in one go! With this script, you can: ✅ Exports mailbox sign-in status into a neat CSV file. ✅ Identifies sign-in settings for shared mailboxes. ✅ Tracks sign-in configs for room mailboxes. ✅ Reviews sign-in status for equipment mailboxes. ✅ Blocks sign-in for all shared mailboxes with a single run. ✅ Verifies sign-in setup for specific mailbox types before taking action. ✅ Automatically checks and installs EXO & Graph PowerShell modules if missing. ✅ Lets you modify the CSV and re-use it to selectively block mailbox sign-ins. ✅ Generates a detailed log post-action, so you know exactly what changed. ✅ Supports MFA and certificate-based authentication (CBA). That's a lot bundled in a single PowerShell script! This script makes sure your shared mailboxes stay shared-only, just the way they should be. You can download the script from here:😊 https://lnkd.in/gZgW9w6r #PowerShell #SharedMailbox #ExchangeOnline #PSscript #MailboxManagement #Outlook

148

5 Comments

📣 Accessibility Professionals, Bookmark This. My good friend Natalie MacLees from AAArdvark Accessibility just launched something the entire accessibility community has been asking for: 🔍 WCAG in Plain English https://lnkd.in/gYGUM8vR This site breaks down each WCAG success criterion into straightforward, human-readable language; designed specifically for accessibility professionals, content creators, designers, developers, and educators. No jargon. No gatekeeping. Just clarity, context, and community-forward accessibility. ✨ Why it matters: Helps bridge the gap between standards and implementation Makes WCAG digestible for teams outside of dev Encourages shared understanding and accountability Supports real-world conformance, not just checkbox compliance 🙌 Please support Natalie’s work by exploring, bookmarking, and sharing this essential resource. #Accessibility #WCAG #InclusiveDesign #A11y #DigitalInclusion #AccessibilityEducation #PlainLanguage #GracefulWebStudio #DesignWithGrace #AardvarkAccessibility #WCAGinPlainEnglish

126

8 Comments

We're considering ways that IT departments can more confidently deploy Obsidian to employees and students. What do you think about this approach? 1. New policy.json file with options for disabling community plugins, themes, Sync, Publish 2. Command line options for --policy-file "path/to/policy.json" 3. Command line options for --policy-json "{json contents}" 4. Environment variable for OBSIDIAN_POLICY_FILE and OBSIDIAN_POLICY_JSON same as the command line options

110

7 Comments

One of the most valuable skills in technical writing... Is staying open to learning. It’s essential for sharpening your craft, Especially in a field that never stops evolving. Standards shift, tools upgrade, and user expectations change constantly. Yet, some writers cling to “what’s always worked.” But success in technical writing comes from curiosity, adaptability, and refinement. You don’t have to master every new tool overnight. But if you stay curious, flexible, and open to feedback, You’ll stay ahead in the field. Here are 7 ways to embrace learning as a technical writer: 1️⃣ Ask questions, even the obvious ones. Clarity is key to good documentation. 2️⃣ Collaborate with cross-functional teams. You’ll learn more by stepping outside your bubble. 3️⃣ Seek feedback on drafts early. It’s easier to adjust before finalizing. 4️⃣ Experiment with new tools and formats. Staying stagnant is the real risk. 5️⃣ Start small, but start now. Growth happens faster when you take action. 6️⃣ Revisit your older work. What could you improve with what you know now? 7️⃣ Learn from users, not just experts. User feedback is your ultimate guide. The best technical writers aren’t perfectionists; they are learners. They grow by staying curious, accepting change, and improving with every project. What’s one way you stay teachable? Let us know below. Want more career insights for technical writers: 1. Follow Technical Writer HQ 2. Like the post. 3. Repost to your network.

121

10 Comments

IAAP Members Explore the Mini Courses Pilot 🎓 Designed for Lifelong Accessibility Learning: https://shorturl.at/TFdHQ IAAP is piloting a new Mini Courses Library, bite-sized, self-paced lessons designed for professionals looking to build or refresh specific accessibility knowledge. 1. Earn 4 CPACC credits per course program 2. Available until August 15 3. Open exclusively to IAAP Members during pilot phase Courses programs include: 1. Disability Etiquette 2. Accessibility Basics 3. Inclusive Tourism Essentials Until 15 August, IAAP is running this pilot, and we’d love your input. Try it out and share your thoughts to help us make it even better! During the pilot phase only IAAP Members will be able to access our new Mini Courses Library. #AccessibilityEducation #InclusiveLearning #ProfessionalEducation #IAAPMembership

65

3 Comments

Don't believe the hype: 🛠️ Automated #accessibility testing tool vendors will tell you their tool can find more issues than it can. 🤖 #AI infused accessibility testing tool vendors will tell you their tool can find more issues than it can. https://lnkd.in/eWK-8ssK

37

5 Comments

Being a technical writer today isn’t just about “writing docs.” If you don’t understand SEO (and now AI SEO), your docs will get buried where nobody can find them. Here’s the truth: • Google (and even AI search tools) don’t care about how hard you worked on your documentation. • They care about how well your docs are structured, described, and optimized. Some quick wins 👇 ✅ Always add a clear, keyword-rich title in your front matter. ✅ Write a concise meta description, this is what search engines use to understand your page. ✅ Don’t just pick any SSG. Use one that supports SEO-friendly defaults. ✅ Add alt text to your images, it’s not just for accessibility, it helps your docs rank. Technical writing + SEO = discoverable docs. Technical writing + no SEO = wasted effort. I share tips like this in my newsletter, it’s back live again. If you want to level up your documentation skills, sign up so you don’t miss my upcoming strategies.

45

5 Comments

I have a quick accessibility tip - it’s better to left align the text on a page! Text that’s centered or justified is often harder for us to read. Centered text can be harder to read because each line starts in a different place. That means it’s easier to miss a line when reading it. And lots of us skim when we’re reading content online already, so anything that makes it harder to read will make people more likely to skip things. This also matters for people who use zoom to see things more clearly. Not having a clear starting point for each line can make it more difficult to figure out where to scroll to next. Justified text can be harder to read because the spacing in between words gets weird. Little “rivers” of white space make it harder to tell which line goes with what. It’s okay for things like titles or text within buttons to be centered. This is more about text that has multiple lines! Left aligned text is easier for most of us to read. And we want people to be able to read the content on our sites, so this is a good way to make it easier for that to happen! Here are some resources if you want to learn more: - Why Justified (or Centered) Text is Bad for Accessibility from BOIA (article) - https://lnkd.in/eaJCuisw   - Supplemental Guidance: Text Justification from the W3C (article) - https://lnkd.in/ezZydj6H - Why You Should Never Center Align Paragraph Text from UX Movement (article) - https://lnkd.in/eHzBPAHp

47

8 Comments

When you're navigating around a website, you'll likely notice certain visual clues that help you out (think header, footer, etc). But people who use assistive technologies like screen readers can't rely on these same clues. This is where Landmarks come in - and here, Ilknur explains how to use them to improve your site's accessibility. https://lnkd.in/gbfJWQRn

53

6 Comments

Accessibility tip: Reading order isn't always left to right and top to bottom. The term "reading order" refers to the path that screen readers follow through the content. When a user selects the down arrow, the screen reader goes to the next point on the path. The next point could be text, an image, or an interactive element. But it should make sense based on the intended user experience. Luckily, we can customize the reading order to fit how we want people to use the product. For example, in PDF, we set the order by adjusting the sequence of the tags in the Tags Panel. PowerPoint also has a Reading Order Pane located at Review / Check Accessibility. The reading order should match the visual flow of the page. For content in European languages, this is usually left to right and top to bottom. But not always. Consider the example in the post image. It shows a page from a grade-school reader. An illustration fills the top two thirds of the page, and the story text is below it. In terms of reading order, this is pretty straight forward, right? The illustration is above the story text. So, it should come first. Not so fast. Reading order also affects how people use alt text. Alt text is contextual. In other words, the way we describe an image depends on how it relates to the other content. In this case, the story text is the main narrative. It introduces an action or event. The illustration then expands on the story text. It represents the action or event in more detail. So, the story text provides *context* for the image description. It helps readers understand why the alt text includes certain details or words. If that's the case, where should the story text be in the reading order? Before or after the illustration? I vote for "before." That way, readers are prepped to understand the alt text when they first encounter it. They don't need to mentally backtrack to figure out how the picture represents the story. In the end, reading order isn't just about position. It's also about purpose. Image note: The image is described in the body of the post. #accessibility #education #EdTech #K12 #publishing

60

19 Comments

People have asked me over the years how they can get better at writing, so a few years back I wrote up a list of advice. If you want to fine-tune how you communicate professionally, take a look! https://lnkd.in/gB2a_i8S Some guidance I still pay attention to in my own writing: - Prefer the more precise word — use "after" instead of "once", or "because" instead of "since". - Avoid unclear antecedents — learning German helped me value relative pronouns, but I'll never look at the word "this" the same way after I learned about unclear antecedents... - May, might, and can have different definitions — use may for permission, might for possibility, and can for ability. What writing guidance has stuck with you in your career?

137

13 Comments