Pierce Devol

I’ve noticed a troubling trend in the market—PDF remediation and accessibility compliance (ADA / WCAG) being offered at extremely low prices. Let’s be clear: PDF remediation is not a quick or automated task. It requires: ✔ Correct logical reading order ✔ Proper heading structure and nesting ✔ Accurate alt text for images ✔ Table headers and scope ✔ Color contrast compliance ✔ Manual testing with screen readers ✔ Passing Adobe Accessibility Checker and WCAG standards Another serious issue I’m seeing: 👉 One project often has multiple middlemen (mediators)—each taking a cut—while the actual accessibility specialist is expected to deliver expert-level work for a fraction of a fair price. This results in: ❌ Unfair compensation for skilled professionals ❌ Rushed or incomplete compliance ❌ Higher risk of audit failure and legal exposure for clients ❌ A damaged reputation for the accessibility industry Accessibility is about equal access, not shortcuts. Clients deserve real compliance, and accessibility professionals deserve fair pricing and direct collaboration—not a race to the bottom. Let’s raise the standard, not lower the price. ♿📄 #Accessibility #PDFRemediation #WCAG #ADACompliance #Freelancing #DigitalAccessibility #FairPay #QualityOverPrice

35

6 Comments

If people keep asking the same questions, the problem isn’t them—it’s your documentation. Maybe it’s buried under five layers of folders. Maybe it’s too vague to be useful. Maybe it’s just painful to read. Good documentation doesn’t just exist—it works. ✔ Make it easy to find. (No, “search the wiki” isn’t an answer.) ✔ Write like a human. (Not a spec sheet.) ✔ Give people what they actually need. (Not what you assume they need.) If you’re answering the same question over and over, your docs aren’t doing their job. Fix them. Follow Andrew Eroh for more technical writing tips. #TechnicalWriting #Documentation #ClearCommunication #WritingThatWorks

11

5 Comments

This week, I've been thinking about how to reduce documentation friction for my client's development team, and diving into The Good Docs Project's templates to see if they would be a good start. Reader, they are so good! The templates cover the key information types (content, how-to, tutorial, reference), plus much more. They all come with stacks of guidance and examples. Developers can choose to read all of the guidance and learn tech writing skills, or they can just grab a template and get cracking. I really recommend taking a look at the templates and exploring the project repo: https://lnkd.in/eBqrpneV #technicalwriting #techwriting #documentation

23

3 Comments

Documentation systems often assume reasoning will be obvious. It rarely is. Engagement teams understand the file while building it. Reviewers see it after context has faded. Inspectors see it without internal history at all. If documentation relies on shared memory, defensibility declines with each review layer. Design must anticipate distance. #AuditQuality #InspectionReadiness

5

1 Comment

Documentation isn't a "one and done" task; it’s a living ecosystem that requires constant synchronization with the product it supports.

1

What stood out immediately from the State of Docs 2025 report was this paragraph: "Documentation plays a huge role when companies are deciding what products to buy. More than 90% of the leaders and engineers we surveyed said documentation was either “extremely important” or “somewhat important” in their decision-making. Only 2% said it wasn’t important at all." What surprised me was that 78.6% mentioned that product documentation helped them decide to buy a product, while only 31.8% said customer success stories did To be honest, I thought it would've been the opposite. I wonder, however if the opposite is true for tech services? Meaning, case studies play a bigger role for tech services. Big thanks to the #techwriters who shared this report in my feed. #documentation #tech

2

One of the biggest parts of being a tech writer is building those relationships across departments and creating trust and earning credibility as a partner in producing something helpful and clear for the end user.

1

2 Comments

[1/5] If you want to grow and learn quickly as a technical writer, follow these five pace-setters: Curt Robbins → Senior Technical Writer & Instructional Developer He has over 15 years of industry experience and has dedicated his time to creating loads of technical writing resources, including articles, newsletters, podcasts, tool reviews, and tutorials. He also runs a technical writing agency. Michael Clark BA (Hons) Technical Author, Trainer. Plain English He has over 25 years of experience in technical writing. I have accrued values from his tools review and insightful articles. If you want to become a technical author, he is one person you should follow closely. Manny Silva → Head of Documentation & Founder He wears many hats as an experienced documentation engineer and technical writer. He is also one of the leading authorities on "Docs as Test," having published a book on the "tool-agnostic strategy" for technical documentation. Opemipo Jokotagba → Technical Writer & Documentation Engineer He is experienced in both corporate and freelance technical writing, as well as software development. Trust me, his digital footprints are everywhere on this platform. I find his engagements highly insightful. Wisdom Nwokocha → Senior Technical Writer & Open Source Founder Apart from his experience in developer documentation and technical writing, he regularly contributes to open source and developer advocacy. He is also a mentor who organizes API and Product Documentation cohorts for aspiring technical writers. Note: This is a very sentimental list and I can't possibly mention everyone in one post. There will be a sequel soon, I promise. In the meantime, follow and join these communities to meet like-minded individuals and benefit from their vast pool of resources; Technical Writer HQ Technical Writing Mentorship Program The Good Docs Project WriteTech Hub Write the Docs Be very intentional about networking in November. Feel free to mention other trailblazers who should make the list. I'll be looking forward to your feedbacks. #Technicalwriting #Documentation

42

27 Comments

Yes, the software or service you built needs documentation. Yes, it will cost you MORE MONEY if you don't have good documentation. Yes, it will save you MORE MONEY if you support and foster good documentation efforts by your teams. Yes, it will save training time, resources, and headaches. Yes, your support or customer service teams (and customers) will be thankful that it's there. No, you don't just need documentation for administrators or deployment experts; you need it for your user pools as well. No, you should NOT consider it as the "last part" of a deploy, project, or initiative.

30

Seeing as how we’re twenty-five years into the 21st century, can we please talk about why you think I need a degree to do my job - when I’ve been successful without one for a decade and a half?   I estimate that for every ten technical writing roles I’ve applied for in the last three months, I’ve made a hard pass on another ten. Because their job descriptions read like wish lists written by someone who doesn’t know what they’re wishing for.   In the last two days, I’ve read two entry-level job descriptions I’m not technically ‘qualified’ to fulfill – and I'm a seasoned veteran. It’s not just me, either; I’m seeing the same gripe from experienced writers all over LinkedIn. Is there any hope that decision-makers could stop using degree-level education as a proxy for competence, and start focussing on what really matters – like demonstrable experience that's yielded quantifiable results?   Every time a company says ‘Bachelor's degree required’, they're: - Excluding qualified, experienced candidates who would probably excel. - Maintaining barriers that disproportionately affect those to whom university education wasn’t an option. - Shutting out unconventional thinkers and non-traditional career paths. - Perpetrating a heinous waste of capability by box-ticking credentials. - Invalidating lateral thinking and pattern-recognition skills that are only obtainable through hard experience.   Even if a degree is everyone’s go-to screening metric, that doesn’t mean reliance on that metric isn’t the height of laziness. What’s stopping you from being specific and to-the-point about characteristics I actually need to do my job? Surely, not ignorance about what it takes to do my job? ‘Ability to independently build turn-key user documentation sets.’ Check. ‘Advanced grammar and language manipulation skills.’ Check. ‘Experience in multiple industries.’ Check.   The best talent you’re going to find may not have a diploma or degree. But they DO have the ability to get the job done to a high standard, on time, and on budget.   I recently read a declaration that the best technical writers are harder to net than Alaska King Crab from a sinking trawler during a seasonal hurricane. Here I am, searching for a crab pot. If you want the best, why are you dangling a rusty hook off the end of the dock, and getting indignant that choice seafood isn’t jumping out of the water and into your lap? It’s the Information Age. Why are you still hiring as if it’s 1955? #thismakesnosense #isittheworldorisitme #ohyeoflittlefaith #itsunconventionalnotinvalid #paperdoesnotequalexperience #technicalwriters #hireme #hireahuman

5

1 Comment