ListenFeaturesAboutDiscord

Accessibility Statement

Last updated: July 9, 2026 (accessibility is an ongoing journey, not a destination)

THIS ACCESSIBILITY STATEMENT (THE “STATEMENT”) DESCRIBES THE OPERATORS' COMMITMENT TO DIGITAL ACCESSIBILITY, THE ACCESSIBILITY STANDARDS TO WHICH THE SERVICE ASPIRES TO CONFORM, THE ACCESSIBILITY FEATURES THAT HAVE BEEN IMPLEMENTED, THE TECHNICAL SPECIFICATIONS UPON WHICH THE SERVICE RELIES, AND THE PROCESS BY WHICH USERS MAY PROVIDE FEEDBACK OR REPORT ACCESSIBILITY BARRIERS. THE OPERATORS BELIEVE THAT THE INTERNET SHOULD BE ACCESSIBLE TO EVERYONE, REGARDLESS OF ABILITY, AND ARE COMMITTED TO MAKING THE SERVICE AS INCLUSIVE AND ACCESSIBLE AS REASONABLY POSSIBLE, GIVEN THE CONSTRAINTS OF A SMALL COMMUNITY PROJECT WITH LIMITED RESOURCES.

SECTION 1. OUR COMMITMENT TO ACCESSIBILITY AND THE PHILOSOPHICAL AND PRACTICAL UNDERPINNINGS OF OUR APPROACH TO INCLUSIVE DESIGN

1.1 Statement of Commitment

erlc.fm is committed to ensuring digital accessibility for people with disabilities. The Operators recognize that access to information, entertainment, and community is a fundamental right, and they are dedicated to providing a Service that is usable by the widest possible audience, regardless of ability, disability, technical capability, or assistive technology. The Operators are continually improving the user experience for everyone by applying relevant accessibility standards, conducting regular accessibility reviews, addressing identified issues, and incorporating accessibility considerations into the design and development process for new features and updates.

1.2 Scope of This Commitment

This commitment to accessibility applies to all aspects of the Service that are under the Operators' control, including but not limited to: the web interface, the audio player, the navigation system, the music request interface, the voting system, the now-playing display, the settings and preferences pages, the Discord bot commands and responses, the API endpoints, and any other features, functionalities, or components of the Service that are designed, developed, maintained, or operated by the Operators. This commitment does not extend to third-party content, embedded third-party players (such as the YouTube embedded player), third-party platforms (such as Discord), or any other elements of the Service that are outside the Operators' direct control.

1.3 Limitations and Acknowledgment

The Operators acknowledge that erlc.fm is a small, community-driven project operated by a limited number of individuals with limited resources, time, and expertise in accessibility. While the Operators are committed to accessibility and strive to implement best practices, the Operators acknowledge that the Service may not be fully accessible to all users at all times. The Operators are committed to continuously improving accessibility and welcome feedback from users who encounter accessibility barriers. The Operators make no representation or warranty that the Service meets any particular accessibility standard, guideline, or requirement, and expressly disclaim any liability arising from or related to any failure to achieve any such standard, guideline, or requirement.

SECTION 2. CONFORMANCE STATUS AND THE SPECIFIC ACCESSIBILITY STANDARDS TO WHICH THE SERVICE ASPIRES TO CONFORM, ALONG WITH THE DETAILS OF OUR CURRENT LEVEL OF COMPLIANCE AND THE AREAS WHERE WE ACKNOWLEDGE SHORTFALLS

2.1 Web Content Accessibility Guidelines (WCAG)

The Web Content Accessibility Guidelines (WCAG) define requirements for designers and developers to improve accessibility for people with disabilities. WCAG is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG defines three levels of conformance: Level A (minimum conformance), Level AA (mid-range conformance), and Level AAA (highest conformance). Each level includes a set of success criteria that must be satisfied for a web page or application to be considered conformant at that level.

2.2 Current Conformance Status

erlc.fm is partially conformantwith WCAG 2.1 Level AA. “Partially conformant” means that some parts of the content, features, or functionality of the Service do not fully conform to the WCAG 2.1 Level AA success criteria. The Operators have identified the following areas where full conformance has not yet been achieved:

  • Third-Party Embedded Content: The YouTube Embedded Player, which is used to stream music video audio, has its own controls and interface that are not under the Operators' control. The accessibility of this embedded player is governed by YouTube/Google's own accessibility practices, and the Operators cannot guarantee that it meets any particular accessibility standard. Users who rely on assistive technologies may experience accessibility barriers when interacting with the YouTube Embedded Player.
  • Real-Time Audio Stream: The Service transmits a continuous audio stream that may not include captions, transcripts, or text alternatives for the lyrics or verbal content of the music being played. The Operators acknowledge that this may create accessibility barriers for users who are deaf or hard of hearing and are exploring options for providing additional accessibility features in the future, subject to technical and resource constraints.
  • Dynamic Content Updates: Some areas of the Service that update dynamically (such as the now-playing display, the song request queue, and the voting interface) may not fully announce changes to assistive technologies in all cases. The Operators are working to improve the accessibility of dynamic content updates through the use of ARIA live regions and other techniques.
  • Legacy Features: Certain features that were developed in earlier versions of the Service may not meet current accessibility standards. The Operators are gradually updating these features as part of ongoing maintenance and improvement efforts.

2.3 Target Conformance Level

The Operators' target is to achieve and maintain WCAG 2.1 Level AA conformance for all features and functionality under their direct control. The Operators aim to reach this target within a reasonable timeframe, taking into account the resources available and the complexity of the required changes. As new features are developed, they will be designed and implemented with WCAG 2.1 Level AA conformance as a target. The Operators will provide updates on their progress toward this target through the Discord server and through periodic updates to this Statement.

SECTION 3. ACCESSIBILITY FEATURES AND THE SPECIFIC DESIGN CHOICES AND IMPLEMENTATIONS THAT HAVE BEEN MADE TO IMPROVE THE ACCESSIBILITY OF THE SERVICE FOR USERS WITH VARIOUS DISABILITIES AND IMPAIRMENTS

3.1 Keyboard Navigation

erlc.fm is designed to be fully navigable and operable using a keyboard alone, without requiring the use of a mouse, trackpad, touch screen, or other pointing device. Specific keyboard navigation features include:

  • Focus Management: All interactive elements, including but not limited to buttons, links, form controls, and custom widgets, are focusable using the Tab key (and Shift+Tab to navigate backwards). Focus indicators are clearly visible and meet WCAG contrast requirements.
  • Logical Tab Order: The tab order follows the visual layout of the page in a logical, predictable sequence that reflects the reading order and functional relationships between elements.
  • Keyboard Shortcuts: The Space key can be used to play or pause the audio stream when the player controls are focused. Additional keyboard shortcuts may be implemented in future updates to enhance keyboard navigation and efficiency.
  • No Keyboard Traps: There are no keyboard traps on the Service (i.e., there is no point where keyboard focus becomes stuck and cannot be moved away using standard keyboard commands). All elements that receive focus can be unfocused using standard keyboard commands.
  • Skip to Content Links: The Service may include skip navigation links that allow keyboard users to bypass repeated navigation elements and jump directly to the main content of the page, reducing the number of keystrokes required to access the primary content.

3.2 Screen Reader Support

erlc.fm is designed to be compatible with screen reader software, including but not limited to JAWS (Job Access With Speech), NVDA (NonVisual Desktop Access), VoiceOver (built into macOS and iOS), TalkBack (built into Android), and Narrator (built into Windows). Specific screen reader support features include:

  • Semantic HTML5 Structure: The Service uses semantic HTML5 elements (such as header, nav, main, section, article, aside, footer) to provide meaningful structure and landmarks that screen readers can use to navigate the page efficiently.
  • ARIA Landmarks and Roles: ARIA (Accessible Rich Internet Applications) landmark roles and regions are used to identify the purpose of different areas of the page, making it easier for screen reader users to navigate to the content they need.
  • Descriptive Labels: All interactive elements, form controls, and custom widgets have descriptive, accessible labels that clearly communicate their purpose and function. Where visual labels are not present, ARIA labels (aria-label, aria-labelledby) are used to provide equivalent information to screen readers.
  • Live Region Announcements: Dynamic content changes, such as updates to the now-playing display, the song request queue, and the voting interface, are announced to screen readers using ARIA live regions (aria-live=“polite” or aria-live=“assertive” as appropriate) to ensure that users are aware of important changes without losing context.
  • Alternative Text: Images, icons, and graphical elements that convey information include appropriate alternative text (alt attributes) that describes the content and function of the image. Decorative images that do not convey information are marked with empty alt attributes (alt=“”) to prevent screen readers from announcing them.
  • Status Messages: Status messages, error messages, success confirmations, and other notifications are implemented in a way that is accessible to screen readers, using appropriate ARIA roles (role=“status”, role=“alert”) or live regions as appropriate.

3.3 Visual Design and Contrast

erlc.fm features a dark-themed user interface that has been designed with visual accessibility in mind:

  • High Contrast: High-contrast color combinations are used throughout the interface to ensure legibility for users with low vision, color vision deficiencies, or other visual impairments. Text and background color combinations meet or exceed the WCAG 2.1 Level AA contrast ratio requirements of 4.5:1 for normal text and 3:1 for large text.
  • Color Independence: Information is not conveyed through color alone. Where color is used to indicate status, state, category, or other information, an additional visual indicator (such as text, icon, pattern, or position) is also provided to ensure that the information is accessible to users who cannot perceive color differences.
  • Scalable Text: Text on the Service can be resized up to 200% without loss of content or functionality, using standard browser zoom and text resizing features. The layout remains usable and readable at all supported zoom levels, with no horizontal scrolling required for the main content.
  • Focus Indicators: Clear, visible focus indicators are provided for all interactive elements. Focus indicators have sufficient contrast against the background and are not removed or hidden unless an alternative focus indicator is being provided.
  • Readable Typography: Font families are chosen for legibility, with adequate font sizes, line heights, letter spacing, and paragraph spacing to ensure comfortable reading. Text is not justified (left-aligned) to avoid uneven spacing that can create visual patterns that are difficult for some users to read.

3.4 Audio and Media Accessibility

  • Volume Control: The audio player provides clear, accessible volume controls that can be operated using a mouse, keyboard, touch screen, or assistive technology. The current volume level is displayed both visually (as a percentage or slider position) and programmatically (through ARIA attributes that can be read by screen readers).
  • Play/Pause Control: The play/pause button is clearly labeled and can be activated using any input method. The current playback state (playing or paused) is communicated visually and programmatically.
  • No Auto-Playing Audio: The Service does not automatically play audio with sound unless the user has explicitly initiated playback. This ensures that users who rely on screen readers or who are sensitive to unexpected audio are not surprised by sudden sound.

SECTION 4. TECHNICAL SPECIFICATIONS AND THE SPECIFIC TECHNOLOGIES, STANDARDS, AND FRAMEWORKS UPON WHICH THE SERVICE RELIES FOR ITS ACCESSIBILITY FEATURES

4.1 Technologies Used

The accessibility of erlc.fm relies on the following technologies to work with the particular combination of your web browser and any assistive technologies, plugins, extensions, or other tools installed on your computer:

  • HTML5: Semantic HTML5 markup provides the structural foundation for the Service's content and ensures compatibility with assistive technologies.
  • CSS / Tailwind CSS: Cascading Style Sheets, implemented through the Tailwind CSS utility framework, control the visual presentation, layout, and responsive behavior of the Service, while maintaining accessibility through proper color contrast, scalable units, and focus management.
  • JavaScript / TypeScript: Client-side scripting, written in TypeScript and compiled to JavaScript, enables dynamic functionality, interactive features, real-time updates, and responsive behavior, while maintaining accessibility through proper ARIA implementation, keyboard event handling, and focus management.
  • WAI-ARIA: The Web Accessibility Initiative's Accessible Rich Internet Applications specification is used to enhance the accessibility of dynamic content, custom widgets, interactive elements, and complex user interface components that are not natively accessible through HTML alone.
  • Next.js / React: The Service is built on the Next.js framework and React library, which provide built-in accessibility features and support for server-side rendering, client-side navigation, and component-based architecture.

4.2 Dependencies on User Technology

The accessibility features of the Service depend on your use of a modern web browser that supports the technologies listed above, as well as any assistive technologies or plugins that you may use. The Operators recommend using the most recent version of your preferred browser and keeping your assistive technologies up to date to ensure the best possible experience. The Operators make no representation or warranty that the Service will be compatible with any particular combination of browser, operating system, assistive technology, or device.

SECTION 5. ASSESSMENT METHODS AND THE PROCESSES BY WHICH THE OPERATORS EVALUATE AND IMPROVE THE ACCESSIBILITY OF THE SERVICE

5.1 Assessment Approach

The Operators assess the accessibility of the Service through the following methods:

  • Self-Evaluation: The Operators conduct periodic self-evaluations of the Service's accessibility, reviewing pages, features, and functionality against WCAG 2.1 Level AA success criteria. These evaluations are performed by the Operators themselves using available tools, checklists, and testing protocols.
  • Automated Testing: The Operators use automated accessibility testing tools (such as browser extensions, linting tools, and CI/CD pipeline integrations) to detect common accessibility issues, including but not limited to missing alternative text, insufficient color contrast, missing form labels, and improper heading structure.
  • User Feedback: The Operators rely on feedback from users, including users with disabilities, to identify accessibility barriers and prioritize improvements. The Operators encourage all users to report accessibility issues they encounter.
  • Periodic Review: The Operators review this Accessibility Statement periodically and update it to reflect changes in the Service, changes in accessibility standards, and progress toward accessibility goals.

SECTION 6. FEEDBACK, CONTACT, AND THE PROCESS BY WHICH USERS CAN REPORT ACCESSIBILITY BARRIERS, PROVIDE SUGGESTIONS, AND ENGAGE WITH THE OPERATORS TO IMPROVE THE ACCESSIBILITY OF THE SERVICE

6.1 How to Provide Feedback

The Operators welcome your feedback on the accessibility of erlc.fm. If you encounter any accessibility barriers, have suggestions for improvement, or would like to request an alternative format for any content on the Service, please contact the Operators through the official Discord server, accessible at https://fm.erlc.dev/discord. When reporting an accessibility issue, please include, to the extent reasonably available:

  • The specific page, feature, or component where you encountered the issue;
  • A description of the issue and the accessibility barrier it creates;
  • The browser, operating system, and assistive technology you are using (including version numbers);
  • Any error messages, unexpected behaviors, or other symptoms you observed;
  • Your suggestions for how the issue might be resolved or worked around;
  • Any other information that may be relevant to diagnosing and addressing the issue.

6.2 Response Timeframe

The Operators aim to acknowledge receipt of your accessibility feedback within two (2) business days and to respond with a substantive update, including an assessment of the issue and an estimated timeline for resolution (if applicable), within five (5) business days. However, these timeframes are targets and not guarantees, and the Operators make no commitment to respond within any particular timeframe or at all. The Operators prioritize accessibility issues based on their severity, impact, and complexity, and will make reasonable efforts to address reported issues in a timely manner given the resources available.

SECTION 7. ONGOING IMPROVEMENTS AND THE OPERATORS' COMMITMENT TO CONTINUOUSLY IMPROVING THE ACCESSIBILITY OF THE SERVICE OVER TIME, SUBJECT TO AVAILABLE RESOURCES, TECHNICAL FEASIBILITY, AND COMPETING PRIORITIES

7.1 Future Plans

The Operators are committed to the ongoing improvement of the Service's accessibility. Specific areas of focus for future improvements include, but are not limited to:

  • Expanding the use of ARIA live regions to provide more comprehensive announcements of dynamic content changes to assistive technologies;
  • Improving the accessibility of the song request and voting interfaces;
  • Exploring the feasibility of providing captions, transcripts, or text alternatives for the audio stream;
  • Conducting more comprehensive accessibility audits using a wider range of testing tools and methodologies;
  • Engaging with users with disabilities to inform accessibility improvements;
  • Reviewing and updating this Accessibility Statement on a regular basis to reflect changes and progress;
  • Incorporating accessibility training and awareness into the development process;
  • Evaluating and adopting new accessibility standards, guidelines, and best practices as they emerge.

7.2 Limitations on Improvement Commitment

The Operators acknowledge that accessibility improvement is an ongoing process and that some improvements may be delayed, deprioritized, or ultimately not feasible due to technical constraints, resource limitations, or competing priorities. The Operators make no representation, warranty, guarantee, promise, commitment, undertaking, or obligation regarding the implementation of any specific accessibility improvement within any particular timeframe. The Operators' commitment to accessibility is a good faith commitment and is not intended to create any legal obligation, contractual right, or enforceable entitlement on the part of any user.

SECTION 8. COMPLAINTS AND ESCALATION AND THE PROCESS BY WHICH USERS WHO ARE NOT SATISFIED WITH THE OPERATORS' RESPONSE TO AN ACCESSIBILITY ISSUE MAY ESCALATE THEIR CONCERN

8.1 Internal Escalation

If you are not satisfied with the Operators' response to an accessibility issue you have reported, you may escalate your concern by contacting the Operators again through the Discord server and requesting that your issue be escalated to a higher level of review. The Operators will review escalated issues on a case-by-case basis and will make reasonable efforts to address any unresolved concerns.

8.2 External Remedies

If you believe that the Service has violated applicable accessibility laws or regulations, you may have the right to file a complaint with the relevant regulatory authority in your jurisdiction. The Operators will cooperate with any such investigation to the extent required by applicable law. The Operators encourage you to contact them directly before pursuing external remedies, as many issues can be resolved more quickly and efficiently through direct communication.

SECTION 9. GENERAL PROVISIONS, ACKNOWLEDGMENTS, AND THE LEGAL FRAMEWORK GOVERNING THIS ACCESSIBILITY STATEMENT

9.1 Modifications to This Statement

The Operators reserve the right to modify, amend, supplement, restate, recast, revise, replace, supersede, update, change, alter, edit, correct, clarify, or otherwise change this Statement at any time, in whole or in part, for any reason or no reason, with or without notice, in the Operators' sole and absolute discretion. Such modifications shall be effective immediately upon posting the modified Statement on the Service. The Operators will update the “Last updated” date at the top of this Statement to reflect the effective date of any modifications.

9.2 No Waiver

The failure or delay of the Operators to exercise or enforce any right, power, privilege, or remedy under this Statement or under applicable law shall not constitute a waiver thereof, and shall not preclude any other or further exercise or enforcement thereof or the exercise or enforcement of any other right, power, privilege, or remedy.

9.3 Contact Information

For questions, concerns, inquiries, requests, complaints, grievances, feedback, suggestions, ideas, comments, praise, criticism, or any other communications regarding this Accessibility Statement or the accessibility of the Service, please contact the Operators through the official Discord server, accessible at https://fm.erlc.dev/discord. The Operators will make reasonable efforts to respond to your inquiry within a reasonable timeframe but make no commitment to respond within any particular period or at all.

This Accessibility Statement was written with the sincere belief that the web should be for everyone. The Operators are committed to making erlc.fm as accessible as possible, not because the law requires it (though it often does), but because it is the right thing to do. If you are reading this and have suggestions for how the Service could be more accessible, the Operators genuinely want to hear from you. Accessibility is not a checklist to be completed; it is an ongoing commitment to inclusion, dignity, and respect for all users.