Introducing BoardScribe: Accessible Board Meeting Minutes for WordPress  🔗 **Source:** [Introducing BoardScribe: Accessible Board Meeting Minutes for WordPress](https://www.youtube.com/watch?v=uAB3drCQxLc#walkthrough) > [!note]+ Document Notes > tags: [wordpress-accessibility, civic-tech, public-records, plugin-development, wcag, aria, govtech] > author: Equalize Digital — Steve Jones and William > source: YouTube (content recovered via vidIQ walkthrough) > reference: https://www.youtube.com/watch?v=uAB3drCQxLc > date created: 2026-07-31 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Do not quote or attribute any line to the named authors. > > > [!warning] No verbatim transcript exists — quote blocks deliberately omitted > > YouTube published no captions for this video, and both yt-dlp (bot challenge) and the > > transcript API failed. The source content is a **structured walkthrough generated by vidIQ's > > video-watch analysis** — a description of what happens on screen, in the tool's words, not the > > speakers'. Every other deep-read in this batch uses `> [!quote]` blocks for verbatim author > > text; **this one contains none, because none exists.** Technical specifics below (ARIA > > attributes, field names, shortcode) are reported by the analysis tool and should be verified > > against the plugin itself before being relied on. > > # 🏷️ Title > > Introducing BoardScribe: Accessible Board Meeting Minutes for WordPress — Equalize Digital > > # 🧭 Table of Contents > > 1. Summary > 2. Main Content / Notes > 3. References > 4. Paraphrase > 5. Newsletter > 6. Action Items > 7. Hypotheses > 8. Methodology > 9. Questions > 10. Future Research > 11. Implications > 12. Learning Styles Assessment > 13. Accessibility Assessment > 14. DEIB Assessment > 15. Logical Validity > 16. DARVO Analysis > 17. Conclusion > 18. Refactor Appendix > 19. Template Library > > # 🔗 References > > - **Equalize Digital** — the plugin's developer; also makers of Accessibility Checker > - **BoardScribe** — free version under review on WordPress.org at time of recording; Pro version planned > - Shortcode `[edbs_boardscribe]`; block "Board Meetings" (`/board`) > - Sunshine Law / open-meetings compliance — the stated regulatory driver > - WCAG techniques referenced by implementation: ARIA live regions, `scope` attributes, `role="rowgroup"`, `role="rowheader"` > > # 📝 Summary > > **What happened.** A ~66-minute demonstration of BoardScribe, a WordPress plugin for publishing board meeting agendas and minutes in an accessible, searchable format. Free version covers a custom post type, shortcode/block display, and pagination; Pro adds taxonomies, native document pages, livestream and transcript fields, timeline view, and CSV import. > > **Why it matters.** The target users — city councils, county governments, school boards, HOAs, nonprofits — are legally obliged to publish records and are among the least equipped to do it accessibly. The plugin's most consequential design decision is the Pro feature that **replaces linked PDFs with WordPress pages**, which addresses the actual accessibility failure in civic publishing rather than the one that is easy to fix. > > **Stakeholders.** Public bodies subject to open-meetings law; agencies serving government clients; disabled constituents attempting to access public records; the WordPress accessibility community. > > **Risks.** The accessibility work described is genuinely detailed, but the demo is a vendor presentation of their own product, and the free/Pro split places some of the most accessibility-relevant capability behind the paid tier. > > **Bottom line.** A well-targeted plugin addressing a real and under-served compliance problem, with one design choice — native pages over PDFs — that matters more than the rest of the feature list combined. > > # 📖 Main Content > <!-- deep-read:sections start --> ## 🗒️ Notes **[00:00–02:42] Positioning.** Steve Jones and a developer named William introduce the plugin. The name derives from *board meetings* + *scribe*. At recording it was under review on WordPress.org for free release. The named audience is specific and unusual for a WordPress plugin: **city councils, county governments, school boards, HOAs, and nonprofits** — organizations with a statutory duty to publish records under Sunshine Law and equivalent open-meetings statutes. These bodies typically have no in-house web capability and a legal obligation they are frequently failing. **[04:35–09:22] The accessibility implementation.** This is where the plugin earns attention, and the specifics are more considered than most WordPress accessibility marketing: - **Descriptive ARIA labels.** Rather than a column of identical "View Agenda" links — a well-known screen-reader failure, since a link list read out of context becomes meaningless — labels are generated as `View agenda for Monday, January 5th, 2026`. - **ARIA live region set to `polite`** for pagination announcements, so page changes are announced without interrupting whatever the screen reader is currently saying. - **Focus management on pagination** — focus moves to the top of the *table*, not the top of the document. This is the detail that signals someone actually tested with a keyboard; the default behaviour dumps users back to the page top and forces them to re-traverse the entire header on every page change. - **Table semantics** — `scope="col"` and `scope="row"`, proper header cells, `role="rowgroup"` and `role="rowheader"`. - **Empty cells emit explicit text** such as `Agenda not available` rather than being left blank. A blank cell is ambiguous to a screen-reader user: absent data or failed render? - **Keyboard-scrollable tables** and responsive stacking on mobile. Taken together these address the specific ways data tables fail non-visually, rather than the generic checklist items (alt text, contrast) that dominate accessibility feature lists. **[09:50–14:13] Free tier — the data model.** A "Board Meetings" custom post type with a Classic Editor meta box carrying four fields: Meeting Date, Agenda URL, Minutes URL, and a **"Meeting Was Not Held"** checkbox. That checkbox is a small piece of genuine domain knowledge. A cancelled meeting is a *record* in open-meetings compliance — the absence must be documented, not merely reflected by a gap in the list. Media Library integration accepts PDFs, Word documents, or images. Titles auto-generate as `Board Meeting - [Date]`. **[14:50–16:00] Settings.** Includes a "Delete Data on Uninstall" toggle. **[15:50–24:50] Shortcode builder.** `[edbs_boardscribe]`, with a UI configuring included years, date ranges, posts per page, PHP-style date format, display templates, CSS classes, column labels, link labels, and hidden columns — with a live preview updating as settings change. **[25:00–36:20] Block editor.** A "Board Meetings" block with sidebar controls mirroring the shortcode builder. Front-end demonstration shows pagination updating browser history and URL, and mobile stacking. **[37:44–40:05] Pro — taxonomies.** Meeting Groups (Work Session, Retreat, Special) and Meeting Types (Regular, Public Hearing). **[40:10–46:30] Pro — BoardScribe Documents.** The most significant feature in the product. Instead of linking out to PDFs, agendas and minutes become **WordPress pages authored in the block editor**, supporting embedded charts, images, text, and video. A single document can attach to multiple meetings. This is the feature that addresses the actual problem. Civic records are overwhelmingly published as scanned or exported PDFs, which are frequently untagged, often image-only, and effectively unreadable by screen readers regardless of how accessible the surrounding page is. A table with immaculate ARIA that links to an inaccessible PDF has moved the barrier, not removed it. Native pages remove it. **[47:04–49:40] Pro — meeting fields.** Date Display Override (e.g. "March Special, TBD"), Location, Livestream URL, Recording URL, **CC Transcript upload** (VTT, SRT, or TXT), and repeatable Supporting Documents rendered as a semantic `<ul>` inside table cells. The transcript field is the second-most-important accessibility feature: it makes the *recording* accessible, closing the loop for deaf and hard-of-hearing constituents attending remotely. **[54:30–56:30] Pro — timeline view**, grouping meetings into styled tables by calendar year. **[62:23–64:30] Pro — CSV importer** with field-mapping documentation, for bulk-importing historical records. Practically important: the compliance obligation is usually retrospective, and a body switching systems has years of back records to move. **[58:00–61:30] Roadmap.** Approval workflows for board members, activity tracking and audit trails, additional design controls. **[64:30–66:15] Close.** Mention of upcoming Accessibility Checker Pro updates and imminent WordPress.org release. # 📚 References Primary sources preferred, and necessary here given the provenance: the BoardScribe plugin listing and documentation on WordPress.org; Equalize Digital's own announcement post; the plugin source for verification of the ARIA implementation claims; WCAG 2.2 techniques for data tables (H63 scope attributes, ARIA live region practices); Section 508 and ADA Title II requirements for public-body web content, particularly the 2024 DOJ rule setting WCAG 2.1 AA as the standard for state and local government — which is the actual regulatory driver behind this product category and is not mentioned in the walkthrough. # 🗣️ Paraphrase A WordPress plugin for organizations that must publish board meeting records — councils, school boards, HOAs, nonprofits — and are usually doing it badly. The free version supplies a post type for meetings with a date, links to agenda and minutes, and a flag for meetings that did not take place. Those render as a table via shortcode or block, with configurable columns and pagination. The accessibility work is in the rendering. Each link is labelled with the meeting it belongs to rather than repeating a generic phrase. Page changes are announced to screen readers politely rather than interrupting. Keyboard focus lands on the table after pagination instead of at the top of the page. Empty cells say why they are empty. The table markup carries proper header scoping. The paid version adds categorisation, and more importantly lets agendas and minutes be authored as WordPress pages rather than linked as PDFs — which is where most civic records become unreadable. It also adds location, livestream and recording links, and an upload for a caption transcript. There is a CSV importer for historical records, and a roadmap covering approvals and audit trails. # 📰 Newsletter **The accessible table that links to an inaccessible PDF** Equalize Digital has a new plugin, BoardScribe, aimed squarely at the least glamorous and most legally exposed corner of the web: city councils, school boards, HOAs, and nonprofits publishing meeting agendas and minutes. The ARIA work in the free version is genuinely careful, and the tell is in the small stuff. Not "we added ARIA labels" but **focus management on pagination** — after you page the table, focus lands on the *table*, not the top of the document. If you have never navigated a paginated table by keyboard, that distinction sounds trivial. If you have, you know it's the difference between usable and abandoning the site. Same with empty cells emitting `Agenda not available` instead of rendering blank, because a blank cell is ambiguous: is the data missing, or did the page break? And there's a "Meeting Was Not Held" checkbox, which is somebody who has actually read an open-meetings statute. A cancelled meeting is a record. The absence has to be documented, not implied by a gap. But the feature that matters most is in Pro, and it's the one worth arguing about: **BoardScribe Documents replaces linked PDFs with WordPress pages.** Here's why that's the whole ballgame. Civic records are published as PDFs — usually scanned, frequently untagged, often just images of text. You can build the most immaculate ARIA table in the world, and if every link in it opens an image-only PDF, you have *moved* the barrier rather than removed it. The table is accessible. The public record is not. Native pages fix the actual problem. Which raises the uncomfortable question: that capability is behind the paid tier, and the audience is small municipalities and volunteer-run nonprofits — the bodies least able to pay and most likely to be out of compliance. Reasonable business model, real tension worth naming. Also in Pro: a CC transcript upload for meeting recordings, which closes the loop for deaf and hard-of-hearing constituents attending remotely. And a CSV importer, which matters more than it sounds — compliance is retrospective, and anyone switching systems has years of back records to move. One caveat on this write-up: **YouTube had no captions for this video.** I recovered the content through vidIQ's video-watch analysis, so everything above is a machine's description of what happens on screen, not the presenters' words. Verify the technical specifics against the plugin before relying on them. A video about accessibility that ships without captions is its own small irony. # ✅ Action Items **DevRel** - The focus-management and empty-cell details are excellent concrete teaching examples for accessible data tables — better than the usual alt-text examples. **OSPO** - Note the pattern: accessibility capability split across free/paid tiers in a market where the least-resourced users have the strongest legal obligation. **Community** - Worth surfacing to agencies serving government and nonprofit clients; this is an under-served niche with a hard compliance deadline. **WordPress subteams** - **Accessibility:** the strongest connection. The ARIA table implementation is worth reviewing as a reference pattern, and the PDF-versus-native-page argument belongs in accessibility guidance generally. - **Themes:** table rendering patterns here are reusable; most theme table markup lacks proper scoping. - **Plugins:** an instance of accessibility-first plugin design worth highlighting in directory curation. - **Documentation:** the "accessible table that links to an inaccessible PDF" problem deserves explicit documentation treatment. - **Training:** civic/nonprofit WordPress use is under-covered in Learn materials; this is a concrete use case. - **Design:** empty-state and focus-management patterns transfer directly. - **Core / Core Performance / Core AI / Core Program Team / Mobile / Playground / Marketing / Support / Photos / TV / Polyglots / Meta / CLI / Hosting / Tide / Openverse:** no direct action from this source. - **The WPOCC:** civic-sector accessibility is a plausible collective focus; member agencies serve exactly this market. - **FAIR:** no direct action from this source. # 🧪 Hypotheses 1. A majority of public-body meeting records published via WordPress are linked PDFs that fail WCAG regardless of the surrounding page's conformance. 2. Focus-management defects in paginated tables produce higher task-abandonment among keyboard users than missing ARIA labels do. 3. Bodies subject to the 2024 DOJ ADA Title II rule will drive measurable demand for civic-records tooling before its compliance deadlines. 4. Native-page publishing produces measurably better screen-reader task completion than accessible-table-plus-PDF for the same records. 5. Free-tier accessibility features are adopted at substantially higher rates than paid-tier ones among small public bodies. # 📊 Methodology **Not applicable — this is a vendor product demonstration**, and additionally the analysis rests on a machine-generated description rather than the source audio. Two distinct evidentiary limitations compound here, and both matter: First, **the source is a sales demo.** Features are shown working by the people who built them, on data they prepared. No independent audit, no screen-reader user testing reported, no conformance report, and no third-party verification of any accessibility claim. The ARIA implementation may well be as described — Equalize Digital's reputation in this space is a genuine reason for confidence — but reputation is not evidence. Second, **the content is doubly mediated.** vidIQ's analysis describes what it observed on screen; I am analysing that description. Specific technical strings (`scope="col"`, `role="rowheader"`, `[edbs_boardscribe]`, `polite`) are reported by a tool that may have read them from screen or inferred them from context. **These must be verified against the plugin source before being cited.** No accessibility claim in this document should be treated as established. What can reasonably be concluded is what the vendor *claims to have built* and *chose to emphasise* — and the emphasis itself is informative. # ❓ Questions - Has the plugin been audited independently, or tested with actual screen-reader users? - What is the free/Pro boundary exactly, and does any WCAG-required capability sit behind the paywall? - Does BoardScribe Documents handle the realistic case — a body that receives agendas as PDFs from its clerk and has no capacity to re-author them? - Are the generated ARIA labels localisable, given the date formatting is embedded in them? - What happens to pagination announcements when a screen reader is mid-utterance — is `polite` sufficient in practice for a table refresh? - Does the CSV importer preserve existing document URLs, or require re-upload? # 🔮 Future Research - Audit of public-body meeting-record accessibility across a sample of municipal WordPress sites. - Comparative user testing: accessible table plus PDF versus native-page publishing, measuring screen-reader task completion. - Study of compliance-driven tooling adoption ahead of ADA Title II deadlines. - Analysis of how accessibility capability is distributed across free and paid tiers in the WordPress plugin market. # 💡 Implications **Practice.** The target users — city councils, school boards, HOAs, nonprofits — are legally obliged to publish records and are among the least equipped to publish them accessibly. A plugin that makes the accessible path the default path does more for compliance than guidance documents do. **Policy.** Which features sit behind the Pro tier is a policy decision, not only a pricing one. When the paid tier holds the feature with the largest accessibility consequence, the organizations least able to pay are the ones publishing the least accessible records — and they are frequently the public bodies with the strongest legal obligation. **Security.** Not applicable to this source. Publishing public records raises no meaningful confidentiality question. **Education.** The audience needs the *why* alongside the tool. A body that installs this without understanding what makes minutes findable and readable will produce compliant-looking output that still fails its readers. **Funding.** Small public bodies buy software from constrained budgets on annual cycles. A subscription-gated accessibility feature competes against every other line item, which is a predictable adoption ceiling. # 🧠 Learning Styles Assessment - **Visual:** Dominant, and this is the source's defining characteristic. A 66-minute screen-share demonstration — nearly all information is conveyed by what is shown. - **Aural:** Cannot be assessed. **No captions exist**, and the audio was not accessible to the recovery pipeline. - **Verbal:** Moderate-to-high technical density in the accessibility sections (ARIA roles, scope attributes, live regions). - **Kinesthetic:** High — the entire video is procedural demonstration; a viewer can follow along in their own install. - **Logical:** Well-structured: naming and positioning, then accessibility rationale, then free tier, then Pro tier, then roadmap. - **Social:** Two-presenter format with host and developer, which typically supports comprehension through question-and-answer. - **Solitary:** Good — the plugin and its documentation are the follow-up path. - **Naturalistic:** Not applicable to this source. **Reading level estimate:** roughly grade 13–15 equivalent for the accessibility sections, which assume familiarity with ARIA and WCAG terminology; the product-tour sections are considerably more accessible, perhaps grade 10–11. # 📊 Accessibility Assessment Mapped to WCAG 2.2 AA. **The finding here is unusually pointed given the subject matter.** 1. **Captions (1.2.2):** **FAILS.** No captions of any kind — not author-provided, not auto-generated. This is a Level A criterion, and it is the reason this document required machine recovery. A 66-minute video about accessibility, published without captions, excludes deaf and hard-of-hearing viewers from content specifically about not excluding them. 2. **Audio description (1.2.5):** **FAILS comprehensively.** This is a screen-share demo where essentially all information is visual — field names, settings, generated markup, live previews. Without captions *or* description, the video is close to unusable non-visually. 3. **Keyboard/navigation (2.1):** Platform-determined. Pass. 4. **Timing / seizure safety (2.3):** No flashing content indicated. Pass. 5. **Reading level (3.1.5):** Fails plain-language targets in the technical sections; appropriate for the developer audience. 6. **Predictable structure (3.2):** Strong — clear progression through naming, rationale, free tier, Pro tier, roadmap. 7. **Assistive-tech compatibility (4.1):** The *product* appears to be built with this as its central concern. The *video about the product* is not. **Stated plainly:** the gap between the plugin's accessibility care and the video's accessibility failure is the most notable finding in this assessment. The Pro tier includes a CC transcript upload field so that *users'* meeting recordings can be captioned — while this video has no captions. That is worth reporting without moralising: it is an extremely common oversight, it is fixable in an afternoon, and the irony is instructive rather than damning. # 🌍 DEIB Assessment - **Cultural breadth:** US-centric by design. Sunshine Law, city councils, school boards, and HOAs are American civic structures, and the compliance framing assumes US law. The underlying need — accessible public records — is universal, but the product framing is not. - **Inclusive language:** No issues identifiable from the walkthrough. Terminology around accessibility appears standard and non-euphemistic. - **Neurodiversity support:** Indirectly strong. Predictable table structure, consistent labelling, explicit empty states, and searchable records all reduce cognitive load for anyone parsing dense civic documents. The timeline view grouping by year is a navigational aid beyond its visual appeal. - **Representation:** Two presenters, both appearing to be men (host and developer). No disabled users are shown using the product, and no user testing is described — a real gap for a product whose entire premise is disabled users' access. The people the plugin exists to serve do not appear in the demonstration of it. - **Psychological safety:** Not a significant dimension for a product demo. Worth noting the framing is compliance-and-capability rather than deficit-focused — accessibility is presented as something the plugin does well, not as a burden imposed on users. **The substantive DEIB observation** is the free/Pro split. The audience is explicitly small municipalities, school boards, HOAs, and nonprofits — bodies with the weakest budgets and the strongest legal obligations. The feature that most directly removes an access barrier (native pages replacing inaccessible PDFs) is in the paid tier. That is a defensible commercial decision and it also means the constituents of the poorest public bodies are the least likely to benefit. Naming it is not an accusation; it is the distributional consequence of the pricing model. # ✅ Logical Validity ## Strong reasoning - **The audience is correctly identified.** Public bodies with statutory publishing duties and no web capability are a real, under-served, legally exposed market — and the product's feature set maps to that population's actual workflow rather than to a generic "tables" use case. - **The accessibility implementation targets real failure modes.** Repeated identical link text, focus loss on pagination, ambiguous empty cells, and missing table scoping are the specific ways data tables fail non-visually — not the generic checklist. Whoever specified this has used a screen reader on a paginated table. - **The "Meeting Was Not Held" field reflects genuine domain understanding.** Under open-meetings law the cancellation is itself a record; a gap in a list does not discharge that. - **The PDF-replacement feature addresses the binding constraint.** The insight that an accessible table linking to inaccessible documents has relocated rather than removed the barrier is the correct diagnosis of civic-records accessibility. - **CSV import acknowledges the retrospective obligation** — compliance covers historical records, not just future ones. ## Fallacies Product demonstrations are not arguments, so these are **evidentiary gaps** rather than fallacies of reasoning: 1. **Demonstration is not verification.** Every accessibility claim is shown working by its builders on prepared data. No audit, no conformance report, no screen-reader user testing. The claims are plausible; none is established. 2. **Absent user voice.** A product whose premise is disabled users' access is demonstrated without any disabled user's involvement being described. This is the most significant gap in the presentation. 3. **Compliance framing without the regulatory specifics.** Sunshine Law is invoked, but the 2024 DOJ rule setting WCAG 2.1 AA for state and local government — the actual and imminent driver — appears nowhere in the walkthrough. Whether that is an omission by the presenters or by the analysis tool cannot be determined from this source. 4. **Free/Pro boundary presented as feature tiers rather than as an accessibility question.** Whether any capability required for conformance sits behind the paywall is not addressed. 5. **Unfalsifiable as delivered.** Nothing in a vendor demo can fail, because the demonstrator controls the data and the path. ## Tone of voice Cannot be assessed directly — no audio was available and the walkthrough describes content rather than delivery. What the *structure* suggests is a thorough, unhurried technical demonstration: 66 minutes for a plugin with roughly a dozen features implies detail over persuasion, and the ordering (accessibility rationale before feature tour) suggests the accessibility work is positioned as the product's substance rather than as a selling point appended at the end. The two-presenter host/developer format typically produces a question-driven register that surfaces implementation detail, which is consistent with the technical specificity the walkthrough captured. **This assessment is inference from structure, not observation of delivery.** Treat accordingly. # 🛡️ DARVO Analysis **Not applicable to this source.** A product demonstration with no accusation, defence, or contested claim. - **Deny.** Not applicable — nothing is being denied. Limitations are simply not discussed, which is a completeness gap rather than denial. - **Attack.** Absent. No competitor, alternative approach, or party is criticised. Notably, the PDF-publishing status quo is treated as a problem to solve rather than as anyone's fault. - **Reverse Victim & Offender.** Absent and structurally inapplicable. **Verdict:** No DARVO. Recorded per template. # 🎯 Conclusion **Bottom line.** The durable idea is one sentence long and generalises well past this plugin: **an accessible interface that links to inaccessible content has moved the barrier, not removed it.** A perfectly marked-up ARIA table whose every link opens an untagged scanned PDF delivers a conformant table and an inaccessible public record. BoardScribe's most significant feature — authoring agendas and minutes as WordPress pages rather than linking PDFs — is the one that addresses this, and it is the reason the product is interesting rather than merely competent. The implementation details worth borrowing regardless of the plugin: focus lands on the *table* after pagination, empty cells state why they are empty, and link labels name what they link to. **What to hold loosely.** Everything technical. This is a vendor demonstration recovered through a machine-generated description — doubly mediated, with no audit, no user testing, and no verification of the specific ARIA strings reported. Confirm against the plugin source before citing any of it. **Next steps.** Check the WordPress.org listing and the plugin source to verify the implementation claims. For anyone advising public bodies: the ADA Title II rule is the actual driver here and goes unmentioned in the source. And for anyone publishing accessibility content — caption the video. # 🧱 Refactor Appendix > [!note] No Literature Split Pad quotes > The Literature Split Pad normally carries verbatim `> [!quote]` blocks. **This source has no > verbatim text** — see the provenance warning at the top. Claims below are paraphrased from a > machine-generated walkthrough and are marked as such. Do not promote any of them to a quote. ## Literature Split Pad (paraphrase only — no verbatim source) ### An accessible wrapper around inaccessible content relocates the barrier *Where:* ~40:10–46:30, the BoardScribe Documents feature. *Why:* the correct diagnosis of civic-records accessibility — conformant tables linking to untagged PDFs produce a conformant table and an unreadable record. Fully generalisable beyond WordPress. ### Focus management is the detail that distinguishes tested from claimed accessibility *Where:* ~04:35–09:22. *Why:* moving focus to the table rather than the document top after pagination is invisible to sighted users and decisive for keyboard users. It is the kind of thing found only by actually using the interface non-visually. ### An explicit empty state is more accessible than an empty cell *Where:* ~04:35–09:22. *Why:* a blank cell is ambiguous — missing data or failed render? Screen-reader text resolves it. ### Compliance obligations are retrospective, so migration tooling is a compliance feature *Where:* ~62:23–64:30, the CSV importer. *Why:* historical records fall under the same duty, which makes bulk import a conformance requirement rather than a convenience. ### A cancelled meeting is itself a record *Where:* ~09:50–14:13, the "Meeting Was Not Held" checkbox. *Why:* small evidence of genuine domain literacy — the absence must be documented, not implied by a gap. ## Atomic Split Pad #### An accessible interface wrapping inaccessible content moves the barrier rather than removing it Conformance at the wrapper measures the wrapper, while the user's actual goal sits in the content it links to. <!-- atomicity: 1 idea ✓ --> #### An explicit empty state carries information that an empty container cannot Blankness is ambiguous between absent data and failed rendering, so stating the reason is what makes it legible. <!-- atomicity: 1 idea ✓ --> #### Where obligation is retrospective, migration tooling becomes a compliance requirement A duty covering historical records makes bulk import part of conformance rather than a convenience feature. <!-- atomicity: 1 idea ✓ --> #### Paywalling the capability that removes an access barrier distributes access by budget When the obligated parties are the least funded, tier placement determines who actually gets served. <!-- atomicity: 1 idea ✓ --> ## Fleeting Queue - #xref The wrapper/content atom is a strong sibling to [[Validation That Inspects Steps Cannot See Composition]] and to the layered-boundary material — all three concern a check or control that is correct at its own layer and irrelevant to the outcome. - #xref "Paywalling the barrier-removing feature" connects to the credentialing atom from the Grandin/Partlow source and to the practical-obscurity economics material — access determined by resources rather than by need. - #xref The captions failure on an accessibility video is a clean instance of a general pattern worth a note: *expertise in a domain does not transfer to one's own artifacts in that domain.* - #articleseed "Your accessible table links to an inaccessible PDF" — for agencies serving civic clients. - Vocabulary: **ARIA live region**, **`polite` announcement**, **focus management**, **scope attribute**, **Sunshine Law**, **open-meetings compliance**. - Lingering question: does any WCAG-required capability sit behind the Pro paywall? The walkthrough does not say, and for this audience it matters. - ⚠️ Provenance: no verbatim transcript exists. All technical specifics come from a machine-generated screen description and need verification against the plugin source. ## Things 3 - Check the BoardScribe listing and source on WordPress.org - Verify the ARIA implementation claims against the actual plugin - Look up the 2024 DOJ ADA Title II rule deadlines for state and local government <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Introducing BoardScribe Accessible Board Meeting Minutes for WordPress.md|Introducing BoardScribe: Accessible Board Meeting Minutes for WordPress by Equalize Digital — Steve Jones and William]] ## Highlights - - **Focus management.** Moves focus to the top of the table after pagination, so keyboard users are not returned to the top of the page. ([View Highlight](https://read.readwise.io/read/01kyx6r4p21q5xt965ebmc0rgd)) - Note: The detail that distinguishes tested accessibility from claimed accessibility — invisible to sighted users, decisive for keyboard users, and only findable by actually navigating the interface non-visually. Same class as the empty-cell text ("Agenda not available") rather than a blank cell. - Tags: atom/literature/h2, wcag, keyboard-navigation - - Replaces external PDF/URL links with dedicated WordPress pages created inside the meeting editor using the block editor. ([View Highlight](https://read.readwise.io/read/01kyx6qv36vh6qtqy3491ga644)) - Note: The feature that matters most, and the generalisable idea: an accessible interface linking to inaccessible content has MOVED the barrier, not removed it. A conformant ARIA table whose every link opens an untagged scanned PDF yields a conformant table and an unreadable public record. Note this sits in the paid tier while the audience is the least-funded, most-obligated bodies. - Tags: wordpress-accessibility, wrapper-vs-content, atom/literature/h1