Accessibility
Python for Everyone
Poetic Bytes is committed to making Python education accessible to all learners, regardless of ability, device, or environment. I believe that learning to code should be a right, not a privilege.
♿ Accessibility Statement
My promise to create an inclusive learning environment for every Python developer
My Commitment
Poetic Bytes is dedicated to ensuring that my platform is accessible to people with all types of disabilities. I continuously work to improve the user experience for everyone and apply the relevant accessibility standards.
I recognise that accessibility is not a one-time effort but an ongoing commitment. As I develop new features and content, I embed accessibility into every step of my process — from design to development to testing. My goal is to provide an equitable learning experience for all Python enthusiasts, regardless of how they access the web.
This page outlines the accessibility features I have implemented, the standards we follow, and how you can provide feedback if you encounter any barriers.
✅ My Accessibility Commitments
Concrete actions I take to ensure everyone can learn Python
- Visual Accessibility — All text meets WCAG contrast ratios (≥ 4.5:1 for normal text, ≥ 3:1 for large text). I never rely on colour alone to convey information.
- Keyboard Navigation — Every interactive element is fully operable via keyboard. Focus indicators are clearly visible. Tab order follows a logical reading sequence.
- Colour Blindness Consideration — I use patterns, labels, and icons in addition to colour to distinguish information. Colour combinations are tested for common colour vision deficiencies.
- Readable Typography — We use a clear, sans-serif font family (Syne) with adequate line height (1.6) and spacing. Text can be resized up to 200% without breaking the layout.
- Screen Reader Compatibility — Semantic HTML elements (headings, landmarks, lists) are used throughout. All images have descriptive alt text. ARIA labels provide additional context where needed.
- Code Accessibility — Code blocks use semantic markup with proper syntax highlighting. The code editor and output panels are keyboard-accessible.
- Focus Management — Focus is managed predictably across interactions. Skip links allow bypassing repeated navigation. Focus indicators are high-contrast and visible.
- Alternative Text — Every meaningful image, icon, and graphic has descriptive alternative text. Decorative images are hidden from screen readers.
- Mobile & Touch Accessibility — Touch targets are at least 44px × 44px. The interface is fully responsive and usable on all screen sizes.
- Regular Testing — I conduct regular accessibility audits using automated tools and manual testing with screen readers (NVDA, VoiceOver, TalkBack).
- User Feedback — I welcome and act on accessibility feedback. Report issues using the form below or contact me directly.
- Continuous Improvement — Accessibility is integrated into my development lifecycle. Every new feature is reviewed for accessibility before release.
⚙️ Accessibility Features on This Site
Specific features I have built to support all learners
Skip to Main Content
A visible skip link appears when you tab to it, allowing keyboard users to bypass navigation and jump straight to the main content.
Full Keyboard Navigation
All buttons, links, and interactive elements are accessible via the Tab key. Focus indicators are high-contrast and clearly visible.
High-Contrast Colours
All text meets WCAG AA contrast requirements. The colour palette is designed to be readable for users with low vision and colour blindness.
Responsive Typography
Font sizes are set in relative units (rem, clamp) so they scale with browser zoom. Line height and spacing are optimised for readability.
Semantic HTML
Proper heading hierarchy (h1–h6), landmark regions (header, nav, main, footer), lists, and ARIA roles make content navigable by screen readers.
Descriptive Alt Text
All meaningful images have descriptive alternative text. Decorative images are marked as presentational and hidden from screen readers.
Visible Focus Indicators
Focus outlines are clearly visible on all interactive elements. The outline colour contrasts with the background for easy identification.
Code Block Accessibility
Code examples use semantic markup with proper syntax highlighting. Copy and run buttons are keyboard-accessible and labelled.
Mobile-Friendly Design
The layout adapts to all screen sizes. Touch targets are at least 44px × 44px. Content reflows without horizontal scrolling.
Zoom Support
Content is readable and functional at up to 200% zoom. No information is lost and no horizontal scrolling is required.
No Reliance on Colour Alone
Information is never conveyed by colour alone. I use icons, patterns, labels, and text to provide context.
Clear Language
Content is written in plain, clear English. Technical terms are explained. Reading level is accessible to a wide audience.
📋 Accessibility Standards I Follow
I align my work with recognised accessibility guidelines and best practices
| Standard | Level | Status |
|---|---|---|
| WCAG 2.1 (Web Content Accessibility Guidelines) | AA | ✅ Compliant |
| WAI-ARIA 1.2 (Accessible Rich Internet Applications) | — | ✅ Implemented |
| Section 508 (US Federal Accessibility) | — | ✅ Aligned |
| EN 301 549 (European Accessibility Standard) | — | ✅ Aligned |
| HTML5 Semantic Elements | — | ✅ Used |
| CSS Media Queries (Responsive Design) | — | ✅ Implemented |
| ARIA Landmarks & Roles | — | ✅ Used |
| Keyboard Accessible (All functionality) | — | ✅ Verified |
About WCAG 2.1
WCAG 2.1 (Web Content Accessibility Guidelines) is the internationally recognised standard for web accessibility. Level AA is the target for most organisations and is considered the minimum for inclusive design. I aim to meet or exceed Level AA across all content and features.
💬 Feedback & Support
I want to hear from you — tell me how I can improve
Your Voice Matters
If you encounter any accessibility barriers while using Poetic Bytes, please let me know. I treat every accessibility issue with priority and work to resolve it as quickly as possible.
Email us directly atpansensoyglenn150@gmail.com with "Accessibility" in the subject line.
Open an issue on our GitHub repository — we respond within 48 hours.
❓ Accessibility FAQ
Answers to common questions about accessibility on Poetic Bytes
I strive for full compatibility with major screen readers (NVDA, JAWS, VoiceOver, TalkBack). I use semantic HTML, ARIA landmarks, and descriptive labels. If you encounter any issues, please report them using the feedback form above — I will investigate and fix them promptly.
Yes. Every interactive element — links, buttons, form fields, code runners, accordions — can be operated using the Tab key, Enter/Space, and arrow keys where appropriate. A visible skip link lets you jump past navigation to the main content.
All text meets WCAG 2.1 AA requirements: normal text has a contrast ratio of at least 4.5:1, and large text (≥18pt) has a ratio of at least 3:1. We test our colour combinations regularly using automated tools and manual verification.
Yes. You can zoom up to 200% using your browser's zoom controls. All text uses relative units (rem, clamp) so font sizes scale correctly. The layout reflows to accommodate larger text without horizontal scrolling.
The site uses a dark theme by default, which many users find easier on the eyes. I also respect your system's high-contrast settings where supported. If you use a browser extension or OS-level high-contrast mode, the site will adapt.
Yes. Code blocks are marked with proper semantics. The code content is readable by screen readers. Copy and run buttons are labelled and keyboard-accessible. The output from code execution is also announced to screen readers.
I xtest regularly with NVDA (Windows), VoiceOver (macOS/iOS), TalkBack (Android), and JAWS (Windows). I also use automated tools like WAVE, axe, and Lighthouse to catch issues early.
Use the feedback form on this page, email me directly at pansensoyglenn150@gmail.com, or open an issue on my GitHub repository. I respond to accessibility reports within 48 hours.
Yes. I write in clear, straightforward English. Technical terms are explained, and I avoid unnecessary jargon. Complex concepts are broken down step by step with examples.
Absolutely. Accessibility is an ongoing commitment, not a one-time checkbox. We incorporate accessibility into our design, development, and testing processes. I also listen to user feedback to prioritise improvements.
📬 Stay updated on accessibility
Get notified when I release new accessibility features or content