Accessibility = consideration - Precious Onyewuchi 🔗 **Source:** [Accessibility = consideration - Precious Onyewuchi](https://www.youtube.com/watch?v=NqS_FcyMWsM) > [!note]+ Document Notes > tags: > - #accessibility > - #inclusion > - #opensourcedesign > - #wordpress > - #ospo > - #education > - #documentation > - #wcag22 > - #alttext > - #captions > - #equity > - #designsystems > - #contributoronboarding > - #zenodo > - #github > Author: Precious Onyewuchi > Source: YouTube Talk (Conference Session) > Reference: https://www.youtube.com/watch?v=NqS_FcyMWsM > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # ♿️ Title: Accessibility = Consideration — Deep Notes & Strategy (Precious Onyewuchi) > <!-- deep-read:sections start --> ## 🧭 Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes (Chronological with Timestamp Links)](#-notes-chronological-with-timestamp-links) - [⏱️ 00:02–01:12 — Intro & Setup](#t-0002) - [⏱️ 01:36–02:12 — Speaker Background](#t-0136) - [⏱️ 02:00–03:10 — Why This Talk Exists](#t-0200) - [⏱️ 03:10–04:14 — Short & Long Definitions of Accessibility](#t-0310) - [⏱️ 04:22–06:12 — Concrete Examples (Alt Text, Keyboard, Infrastructure)](#t-0422) - [⏱️ 06:16–07:24 — Access Tools: Zenodo, DOI, arXiv, GitHub](#t-0616) - [⏱️ 07:48–10:14 — Why Accessibility Matters (Equity, Rights, Longevity)](#t-0748) - [⏱️ 10:14–12:29 — How To Practice: Design, Content, Communication, Allyship](#t-1014) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity & Fallacies](#-logical-validity--fallacies) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### 📚 References: Include a list of sources consulted and cited in the article. (See [📖 References](#-references).) --- ## 📝 Summary: Precious Onyewuchi argues that **accessibility = consideration**—the habit of anticipating diverse user needs from the start. Drawing on experiences from The Turing Way’s accessibility working group, she reframes accessibility as a **behavioral, social, and technical** practice that benefits everyone, not only people with disabilities. Concrete practices include **alt text**, **keyboard operability**, **subtitles/transcripts**, **equity-focused design** (ramps, wider paths), and choosing **open tools** (GitHub, Zenodo/DOIs) to ensure persistent, low-friction access. The call to action: **be proactive, keep language simple, plan accessibility into policies and processes, and be an ally who speaks up.** --- ## 📖 Main Content: - **Core Thesis:** Accessibility is *consideration-in-action*—designing for real people in real contexts, so participation is equitable and sustained over time ([03:10–04:14](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=190)). - **Scope Beyond Disability:** Accessibility addresses barriers faced by **many groups** (e.g., left-handed users, people in noisy spaces, low bandwidth, language differences) ([04:22–06:12](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=262)). - **Open Infrastructure:** Open platforms (GitHub, Zenodo) **lower access cost**, promote reuse, and DOIs make knowledge **durably referenceable** ([06:16–07:24](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=376)). - **Equity vs. Equality:** Equitable design **meets users where they are**, acknowledges changing abilities across life, and prevents costly retrofits ([07:48–09:45](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=468)). - **Practice:** Design inclusive spaces/sites, add alt text & captions, use clear language, ship accessible document formats, and **plan a11y from the start** ([10:14–12:29](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=614)). --- ## 🗒️ Notes (Chronological with Timestamp Links) ### ⏱️ [00:02–01:12 — Intro & Setup](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=2) <a id="t-0002"></a> - [00:05](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=5) Session framed as brief, closing talk; builds on earlier accessibility panel. - [01:06](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=66) Early tech hiccup used to illustrate **practical accessibility** issues (controls, clarity). ### ⏱️ [01:36–02:12 — Speaker Background](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=96) <a id="t-0136"></a> - [01:36](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=96) Open source manager, contributor, and educator. - [02:04](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=124) Origin of talk: **The Turing Way** accessibility group conversation; “accessibility affects everything.” ### ⏱️ [02:00–03:10 — Why This Talk Exists](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=120) <a id="t-0200"></a> - [02:35](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=155) Societal infrastructure reveals values (youth/elderly/disabled are often **underserved**). - [02:59](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=179) Key objectives: **what** a11y is, **why** it matters, **how** to practice. ### ⏱️ [03:10–04:14 — Short & Long Definitions of Accessibility](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=190) <a id="t-0310"></a> - [03:11](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=191) **Short**: Accessibility = **consideration** (design bridges/flows all can use). - [03:31](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=211) **Long (The Turing Way)**: a set of **community-wide behavioral, social, and technical** decisions welcoming participation despite barriers. - [04:00](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=240) Focus on **access for everyone**, with special attention to groups facing recurring barriers. ### ⏱️ [04:22–06:12 — Concrete Examples (Alt Text, Keyboard, Infrastructure)](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=262) <a id="t-0422"></a> - [04:25](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=265) **Alt text** improves screen-reader access & documentation quality. - [04:48](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=288) **Keyboard-accessible** sites support low-vision and motor disabilities. - [05:21](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=321) **Inclusive infrastructure**: ramps, wider paths, **left-handed-friendly** designs. - [05:43](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=343) **Subtitles** help language accessibility & noisy environments; useful for everyone. ### ⏱️ [06:16–07:24 — Access Tools: Zenodo, DOI, arXiv, GitHub](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=376) <a id="t-0616"></a> - [06:19](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=379) Open platforms enable reuse/boilerplates. - [06:32](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=392) **DOIs** create durable, citable links (avoid link rot). - [06:58](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=418) arXiv for research preprints; GitHub as collaboration hub. ### ⏱️ [07:48–10:14 — Why Accessibility Matters (Equity, Rights, Longevity)](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=468) <a id="t-0748"></a> - [08:00](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=480) **Equitable participation**, not just formal equality (box/fence analogy). - [08:22](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=502) Benefits everyone (e.g., subtitles when you can’t use audio). - [08:57](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=537) Abilities change over time; a11y **future-proofs** products. - [09:45](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=585) Avoid costly retrofits; inclusive by design builds **sustainable communities**. ### ⏱️ [10:14–12:29 — How To Practice: Design, Content, Communication, Allyship](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=614) <a id="t-1014"></a> - [10:18](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=618) **Design inclusively**: ramps, wider paths, sensible layouts. - [10:59](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=659) **Accessible content**: alt text, captions, transcripts, **MD/Google Docs** for low-resource access. - [11:26](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=686) Use **clear language**; avoid unnecessary complexity. - [11:49](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=709) **Plan from the start**: policies/processes; be **proactive, not reactive**. - [12:02](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=722) **Be an ally**: speak up when exclusion happens; advocate a11y everywhere. --- ## 📖 References: - Onyewuchi, P. *Accessibility = Consideration* (YouTube): https://www.youtube.com/watch?v=NqS_FcyMWsM - The Turing Way — Guide for Accessible, Inclusive Data Science & Research Communities - W3C **WCAG 2.2**; WAI-ARIA Authoring Practices - GitHub Docs (Markdown accessibility, alt text patterns), Zenodo (DOIs) --- ## 🗣️ Paraphrase: 1) **Definition & Scope** ([03:11–04:04](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=191)) *Original idea:* Accessibility is consideration—choices that let everyone enter and participate, with special focus on groups that face barriers. *Paraphrase:* Think of accessibility as the habit of designing with *other people’s realities in mind*. It’s the collective behavioral, social, and technical choices that let anyone belong and contribute—even when the path would otherwise be blocked. 2) **Equity Over Equality** ([07:48–08:40](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=468)) *Original idea:* Equal treatment isn’t always fair; equitable design meets people where they are. *Paraphrase:* Leveling the field doesn’t mean giving everyone the same stool—it means **adjusting the height** so each person can see. Accessibility aims for that practical fairness that actually works. --- ## 📰 Newsletter: **Accessibility = Consideration (and Fewer Headaches Later)** This week we’re spotlighting a lightning talk from Precious Onyewuchi that nails a simple truth: accessibility isn’t a bolt-on—it’s **consideration**. From alt text and subtitles to keyboard-friendly UIs and clear language, the best time to build inclusion is the **first pull request**. Try this: add an a11y checklist to your GitHub PR template, run a quick keyboard-only pass on your latest theme, and publish transcripts with your tutorials. Want resilient links for your docs or research? Toss a copy on **Zenodo** and grab a DOI. Your future self (and your readers) will thank you. Keep learning: WCAG 2.2, WAI-ARIA, and the WordPress Accessibility Team at make.wordpress.org/accessibility. Be kind, caption everything, and never rely on color alone. 😉 --- ## ✅ Action Items: **You (GoDaddy Developer Advocate, WordPress/OSS educator, aspiring OSPO director):** 1. **Ship A11y PR Template & Teaching Pack (2 weeks)** - PR template with: alt text, headings order, labels, focus state, keyboard-only check, captions for media. - Companion lesson: “First 10 Accessibility Checks for WP Plugins/Themes.” 2. **Adopt Durable Knowledge Links** - Mirror long-form docs on Zenodo to issue DOIs; add DOI badges to READMEs and docs footers. 3. **Contributor Onboarding for Equity** - Create a low-bandwidth onboarding path: Markdown-first docs, downloadable ZIP bundles, transcripted videos. 4. **“Nothing About Us Without Us” Panel-in-Residence** - Quarterly advisory panel of disabled contributors; compensated reviews of GoDaddy WP demos and community tooling. 5. **OSPO-Aligned KPIs** - Track: % PRs passing a11y checklist, caption coverage on videos, keyboard audit pass-rate, average time-to-fix a11y issues, number of DOI’d artifacts. **Reusable Mapping Prompt (paste for future articles):** > “Analyze this article through my roles in WordPress/open source education and advocacy. Identify specific a11y and inclusion practices to adopt in contributor onboarding, documentation, and tooling. Propose measurable OSPO-grade KPIs, a 30/60/90-day plan, and artifacts to ship (PR templates, checklists, demo repos) that advance transparency and inclusivity in the WordPress ecosystem.” **30/60/90 Plan (sketch):** - **30:** Publish PR template + lesson; caption backlog for top 10 videos; create alt-text style guide. - **60:** Pilot advisory panel; run 3 repo audits; release a11y component tokens (contrast/spacing) for Gutenberg blocks. - **90:** Public dashboard of KPIs; DOI issuance for core guides; contributor recognition for a11y fixes. --- ## 🧪 Hypotheses: - **H1:** Requiring an a11y checklist in PRs reduces post-release a11y bugs by ≥30%. - **H2:** Caption-first tutorials increase watch-through rate by ≥15% for non-native speakers and mobile users. - **H3:** DOI-backed docs reduce broken-reference support tickets by ≥25% within 6 months. - **H4:** Involving disabled users in pre-merge reviews improves task success for screen-reader users by ≥20%. --- ## 📊 Methodology: - **Design:** Quasi-experimental before/after across 3–5 WP repos (themes/plugins/docs). - **Data Sources:** GitHub issues/PR metadata, Lighthouse/axe audits, analytics (watch time, bounce rate), support ticket tagging, user testing with AT (NVDA/JAWS/VoiceOver). - **Analysis:** Difference-in-differences on defect rates; Mann-Whitney for non-normal metrics; thematic analysis on interview notes. - **Reporting:** Public quarterly OSPO-style report; anonymized audit datasets; DOI’d whitepaper. --- ## ❓ Questions: - Where in the WP plugin/theme lifecycle do a11y regressions most often enter (design, implementation, docs, QA)? - Which low-bandwidth strategies most improve contributor onboarding in emerging regions? - How can design tokens encode WCAG (contrast/target size) for automatic enforcement in Gutenberg? --- ## 🔮 Future Research: - **Localization & Low-Resource Access:** Best practices for Markdown-first, transcript-rich docs in low bandwidth contexts. - **A11y Design Tokens:** Encoding WCAG into reusable tokens/components for WordPress. - **Inclusive Governance:** Impact of compensated advisory panels on a11y outcomes and contributor retention. --- ## 💡 Implications: - **Practice:** Proactive a11y lowers support costs and broadens audience. - **Policy:** Treat a11y as infrastructure (budget lines, ownership, SLAs). - **Community:** Equity-centered onboarding expands contributor diversity and strengthens sustainability. --- ## 🧠 Learning Styles Assessment: **Estimated Readability:** ~Grade 9–11 (conversational, concrete examples). 1. **Visual (Spatial)** - **Present:** Verbal imagery; references to ramps/paths. - **Improve:** Add diagrams (equity vs equality), a11y workflow swimlane, color-contrast examples. 2. **Aural (Auditory)** - **Present:** Spoken talk; benefits of subtitles. - **Improve:** Provide downloadable audio, chaptered timestamps, and TTS-friendly transcripts. 3. **Verbal (Linguistic)** - **Present:** Clear definitions, analogies. - **Improve:** Glossary (WCAG, DOI, ARIA), links to further reading. 4. **Physical (Kinesthetic)** - **Present:** Implicit (keyboard testing). - **Improve:** Hands-on labs: do a keyboard-only pass; write alt text for 5 images; add captions to a short clip. 5. **Logical (Mathematical)** - **Present:** Cause-effect claims (proactive vs retrofit). - **Improve:** Add metrics dashboards and checklists mapped to WCAG. 6. **Social (Interpersonal)** - **Present:** Community group origins (The Turing Way). - **Improve:** Peer review circles; “a11y buddy” pairing. 7. **Solitary (Intrapersonal)** - **Present:** Reflection prompts implied. - **Improve:** Self-audit worksheet with personal goals. 8. **Naturalistic** - **Present:** Built environment analogies (bridges, ramps). - **Improve:** Case studies on outdoor signage/wayfinding accessibility. --- ## 📊 Accessibility Assessment: - **Screen Reader Semantics:** Use proper **H1–H6**, lists, landmarks; avoid heading skips. - **Alt Text:** Concise, contextual; avoid “image of.” - **Keyboard Navigation:** All controls tabbable; logical order; **visible focus**; no traps. - **Contrast & Readability:** Meet **WCAG 2.2 AA** (≥4.5:1 body); avoid color-only meaning; adequate line spacing & target sizes. - **Text Resizing:** Support 200% zoom without loss; responsive tables/cards. - **Media:** **Captions & transcripts** mandatory; avoid auto-advance carousels. - **Docs for Low Resource:** Prefer **Markdown/HTML** over heavy PDFs; provide downloadable assets. --- ## 🌍 DEIB Assessment: - **Cultural Relevance:** Include multi-region examples (language, bandwidth, devices). - **Inclusive Language:** Plain language; define acronyms; avoid ableist terms. - **Neurodiversity:** Chunk content, predictable layouts, optional simplified summaries. - **Representation:** Feature disabled contributors as **co-authors** and reviewers. - **Psychological Safety:** Public CoC, anonymous a11y feedback, clear response SLAs. --- ## ✅ Logical Validity & Fallacies: **Strengths** - **Causal Reasoning:** Proactive a11y avoids costly retrofits and expands participation ([09:45](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=585)). - **Consistent Analogies:** Ramps/bridges and the fence-stool analogy clarify equity vs equality ([07:48–08:40](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=468)). - **Appeal to Evidence-in-Practice:** DOIs prevent link rot; open tools lower access friction ([06:32](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=392)). **Potential Weaknesses (and Fixes)** - **Appeal to Emotion:** Some persuasive moments lack data. - *Fix:* Pair claims with metrics (bug rates, watch-through, task success). - **Hasty Generalization:** Left-handed/tool examples are illustrative but anecdotal. - *Fix:* Add survey or usability study results across tools. - **Ambiguity of Standards:** “WCA” referenced loosely. - *Fix:* Cite **WCAG 2.2** explicitly and map examples to success criteria. **Tone:** Friendly, practical, community-forward; persuasive without attacking. --- ## 🛡️ DARVO Analysis: **Objective:** Identify Deny/Attack/Reverse Victim-Offender rhetoric. - **Deny:** *Absent.* The talk openly acknowledges shortcomings and proposes remedies ([10:14–12:29](https://www.youtube.com/watch?v=NqS_FcyMWsM&t=614)). - **Attack:** *Absent.* No disparagement of people/orgs; emphasis on systems and practices. - **Reverse Victim & Offender:** *Absent.* Disabled users are centered as stakeholders, not framed as obstacles. **Anti-DARVO Signals:** Clear ownership (“plan from the start”), allyship call, and specific, constructive steps—these promote accountability over deflection. --- ## 🔍 SEO Evaluation: If publishing a recap/post inspired by this talk: 1. **Keywords:** accessibility, inclusive design, alt text, captions, keyboard navigation, WCAG, WordPress accessibility. 2. **Keyword Placement:** Put primary keyword (“accessibility in open source”) in **title**, opening 100 words, H2s, and meta. 3. **Meta Description (150–160 chars):** “Accessibility = consideration: practical steps—alt text, captions, keyboard support, clear language, and DOIs—to build inclusive open-source projects.” 4. **Title Tag (≤60 chars):** “Accessibility = Consideration: Practical A11y in OSS” 5. **Headers:** H2 sections for Why, How, Tools, Checklist, Resources; include relevant keywords. 6. **Length:** Target **1,200–1,800** words; actionable checklists and examples. 7. **Internal Links:** WordPress Accessibility Team, contributor handbook, your a11y checklist repo. 8. **External Links:** WCAG 2.2, WAI-ARIA, Zenodo, The Turing Way. 9. **Images:** Provide alt text; descriptive filenames; compress to <200KB. 10. **Mobile Optimization:** Responsive embeds, no auto-play, readable line length. 11. **Engagement:** CTA to adopt PR checklist, request an a11y audit, join a11y Slack/Make channel. 12. **Schema:** `Article` + optional `FAQPage` (e.g., “How do I write alt text?”). 13. **Social:** OG/Twitter cards with high-contrast thumbnail and concise summary. --- ## 🎯 Conclusion: “Accessibility = consideration” reframes inclusion as *everyday practice*. Start with simple, durable moves—alt text, captions, keyboard support, clear language, DOI-backed docs—and embed a11y into governance, tooling, and contributor education. Plan it from the beginning, measure it like infrastructure, and invite the people most affected to co-design the future of open source. <!-- deep-read:sections end --> ## 📺 Video ![](https://www.youtube.com/watch?v=NqS_FcyMWsM) --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=NqS_FcyMWsM)* **[00:02]** I'll quickly call on the speaker to talk to us about accessibility and considerations in open source right it's going to be very brief so don't worry about you know taking much of your time um please let's make welcome precious oni as she presents the last session for today's conference [Applause] Hello. **[00:33]** >> Okay. >> Hi. My name is Precious oni. I am going to be talking on accessibility equals consideration. Uh first of all, I want to give like a huge shout out to the panel that happened here. It was very very nice and it touched on like really cool points that we should generally give consideration to when we're talking about accessibility. So please next slide **[01:06]** is me that press it. Okay. Sorry. You see, this is not accessible cuz I don't know what. >> Okay. Hi, I already said my name. It's Pasha. **[01:36]** I work as an open source manager and then I also do open source contribution and I'm an open source educator. I have a podcast but I'll say I'll talk about it later. And I generally like I like conversations because they lead to really important topics. I like traveling if I have money and then I like I like learning and nice. So this talk is as a result of a conversation from the Tinway **[02:08]** accessibility group. The Tinway is an open science community. So during one of the meetings le I don't know that's Harry or her but she's the uh accessibility lead for the touring rate community and then during one of the conversations she said that's the thing about accessibility it affects everything it has stuck for a very long time yeah so the origin of this conversation like I've said it's with my friend Zurum **[02:39]** who is also very passionate about how badly built societies like you can tell uh a society that doesn't really care about the young the older people or people who have disabilities by the infrastructure that happen that they have right and then at the accessibility work group meeting uh key takeaways is the what is accessibility why is accessibility important and how can we practice accessibility **[03:10]** uh the short version of what accessibility is is consideration. Thinking about the other person, how would they use this design? How would they be able to cross this road? If you build a pedestrian bridge, if somebody who is using a wheelchair, can they use the steps that you've create that you've built? That sort of thing. And then the longer version according to the Tinway is um accessibility practices are a set of communitywide behavioral, social and technical decision. This is really long so please bear with me and **[03:42]** technical decisions that can be taken to ensure that all are welcome and are able to enter and participate in research datadriven processes communities and events despite any barriers for access. So while accessibility is commonly understood with respect to disability, we meaning the Turingway community define accessibility as giving access to everyone with specific attention given to ensuring proper access for groups of people that encounter different barriers for participation. So the slightly longer version is on the **[04:14]** two-way book. You can read it. Um, an example of accessibility would be descriptive all text for images. How many of us follow Ezra or Luby on Twitter? If you click on his images, you can see like very good descriptions of the image that he has posted and that's a really good example. So it helps screen readers and then it improves documentation and it also benefits cited users because I mean everybody uses and **[04:46]** likes documentation. Um keyboard accessible websites. It aids visually impaired users and also those with motor disabilities. Uh for example, I think if you use keyboards a lot, some people start to develop like carpal tunnel syndrome and it can be bad if you have like a really small screen, right? So using that it's important to make sure that when you you're building websites, people who use mostly keyboards can make use of **[05:17]** them. uh inclusive infrastructure, wheelchair friendly, pedestrian bridges, left-handed friendly book designs. I did not know how much of an issue it was for people who are left-handed to make use of certain tools that we don't really think about until I had a conversation with one of my friend cuz she was crashing out. Right? So, that's an important example. Subtitles for language accessibility and people in noisy areas, right? So like the policy **[05:49]** definition was it's not just related to just disabilities accessibilities is broad and I think the I don't remember her name but the second speaker that was one of the speakers I was seeing here Coco Chem Chem Chem and also for people like me that can sometimes be lazy I find that these days most audios you sent most videos I don't listen to the audio especially like if I'm outside I mostly just read what the captions are right uh access tools like Zenodo, we have GitHub where you're looking for maybe an open source **[06:21]** project, maybe you want to build something and you don't want to build it from scratch, you can easily just find somebody else who has built something similar to what you're looking for and build a boiler plate from it. Uh, Zenodo allows you to have access to research materials and then it al also helps because if you publish your material on Zenodo, you get a DOI, which is a I forgotten what the D is, but the OI is object identifier. Basically, what it means is if you make **[06:51]** changes to your tool, to your material in the future, the same link can still be used in the future. You know, like maybe when you check a website and you see a broken link, that happens probably because the website is no longer accessible or it's been I don't know, maybe maybe the client did not pay the back end developer, so they they removed it. But yeah, if you use a DOI, it makes it's like a sort of like forever type of link that just exists for you. Uh ARXIV, I don't know if it's active, but it's **[07:22]** usually for researchers. And then you have solutions like everybody here is gathered for open source, right? So you have open data, open source, open science. These things give us the ability to have access to materials and just generally really cool communities that you know that you would not most likely have met all these people if you did not have a reason to. Oh no, no, no. That's the main part. Why is why is accessibility important? **[07:54]** Generally because it is really like that's all the thing you need. But then if you're looking for definitions uh accessibility ensures equitable participation for everyone. I don't like equal because I don't think equal is generally fair. Right? If you I don't know if we've seen this meme I mean meme whatever you pronounce it as where me let's do that where uh people are trying to look over a fence and they have the same exactly and then you have **[08:25]** the same length of this but we're not all the same heights. So equitable is reaching people where they are right. So and it also upholds human rights and fairness which is a type of equitability. Uh, it benefits more than just people with disabilities. As for me, I'm not I don't have any disability that I know of, right? But subtitles work for me because like I said, if I'm in a noisy area and you send me a video, I can just know what the content is without listening to it. Uh, **[08:57]** it prepares for changing needs over a lifetime. from the panel there was an example that was given where you may not always I know you you can have an accident you can develop capronal syndrome I used to wear glasses three years ago and then now I wear glasses and if I stay outside too long where the light is is going to be bad so yeah it benefit it's um it prepares for changing it over a lifetime it makes products and services easier for people to use a good design is the one that you don't even **[09:28]** know that it's there uh it helps organizations comply with legal requirements. This is for like a larger part because now when you have things like the is it WCA that has that enforces that people should make sure that their websites are accessible. If you started from scratch, you will not have to again that panel was very very insightful because I can just easily link to it. But yeah, you not have to now start worrying about building like making changes to the house. You built it from the beginning so it's easy. And **[09:58]** then it builds inclusive sustainable communities. People like where they feel heard. People don't like to stay somewhere and they feel excluded. So if you're not being inclusive by design, you're being exclusive subconsciously. How can we practice accessibility? One, you design inclusively, right? I'm not like a designer by profession or anything like that, but design can take many forms. So you can for for infrastructure, we have ramps. Uh, I **[10:30]** think this place probably has like a I I don't remember anymore. But yeah, when you're probably planning events or you're doing anything that involves people coming into a building, it's important to factor places that can um cater to people that don't that would not be able to use stairs, right? Create wider pathways, better layouts for for maybe like websites and then easier navigation like this thing that I don't know what to use. uh create accessible content, add all text, captions, transcripts. **[11:02]** Something I did not add here was making use of formats that are easy for people to access like MD files. If you're probably working with documents, probably use like a Google Docs because Google has really tried to make most of their materials good for low resource settings. So, making use of things that people that don't have so much access to good internet can't work with is a very important factor. uh use clear communication. The older generation they used to show you that they know book with huge **[11:34]** languages. So if you can if something can be simpler, make it simpler. There's really no point making it harder. So yeah, keep language simple. Use accessible formats for documents. Oh yeah, I wrote it here. For example, the MD files. Uh plan accessibility from the start. Build it into policies, processes, and designs. like our star lady said, be proactive, not reactive. And then yes, be an ally. So you may not particularly have a known **[12:04]** disability, right? But if you obviously know that people do, so speak up and advocate for accessibility. If you see somebody being mistreated, speak up. If you see somebody being excluded, speak up for them. Even if it's not like affects you directly. if maybe you see that they're planning an event and [Music] anyway, yes, speak up and advocate for accessibility. Thank you so much.