Accessibility Statement & Policy – The Super PLEG Summit 2026 Website

Last updated: October 8, 2025

Controller / Organizer: Planmore Lateral Entry Solutions (“Organizer”, “we”, “us”) – operator of the Super PLEG Summit one-page website and related online services.

This document contains a full, exhaustive Accessibility Statement plus a practical, standards-aligned Accessibility Policy and Implementation Plan you can publish on the site and use internally. It is written to follow international best practice (WCAG 2.2 / WAI guidance), U.S. Section 508/508-style procurement expectations, and EN 301 549 guidance for EU procurement. (W3C)

1) Short Accessibility Statement

“We are committed to making the Super PLEG Summit website accessible to everyone. We aim to meet Web Content Accessibility Guidelines (WCAG) 2.2 Level AA and to remove barriers in our digital content. If you encounter accessibility barriers, please contact us at Support@SuperPlegSummit2026.com or (+91) 99641 83552 and we will provide a timely alternative.” (W3C)

2) Formal Accessibility Statement

Our Commitment

We are committed to ensuring digital access for people with disabilities. We aim to follow the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA as our target conformance standard and to apply accessibility by design across the website, ticketing, KYC forms, and competition submission workflows. This commitment includes both the public website and content we publish (PDFs, videos, forms, emails, and event materials). (W3C)

Standard Applied

This site is being developed and tested against WCAG 2.2 at Level AA as the baseline standard. Where applicable for procurement or regional compliance, we also monitor and reference Section 508 (U.S.) and EN 301 549 (EU) guidance. The WAI-ARIA Authoring Practices guide is used for interactive widgets that require ARIA semantics. (W3C)

Scope

• The public marketing website and pages on the one-page site.
• The ticketing and payment flows (including third-party payment providers).
• Competition submission pages, dashboards, and administrative portals we operate.
• Documents, PDFs, videos and downloadable resources we publish.
• Embedded third-party content (maps, videos, widgets) where we can control configuration. Note: third-party content may not be fully under our control – see “Third-party content” below.

Known Limitations and Alternatives

We are actively auditing and remediating the site. If you find anything not accessible, or need an alternate format (plain-text, accessible PDF, braille-ready file or telephone support), contact us and we will provide a reasonable alternative promptly. See “Feedback & contact” for how to report issues and the information to include. Best practice guidance on statement content and what to include were used to construct this page. (W3C)

3) Accessibility Features We Implement (technical & content practices)

Structural and Semantic HTML

• Use semantic HTML5 elements (header, nav, main, article, section, footer) and ARIA landmarks to create reliable navigation regions and to help assistive technologies.
• Ensure each page has a single <main> element and accurate page <title> and lang attribute. (W3C)

Keyboard Accessibility

• All interactive functionality is operable with a keyboard alone (Tab, Shift+Tab, Enter, Space, arrow keys where applicable).
• Visible focus indicators are preserved and styled; focus order follows a logical document order.

Skip Links and Logical Structure

• Provide a “Skip to content” link at the top of pages to bypass repeated navigation for keyboard and screen reader users.
• Heading structure is hierarchical (h1 → h2 → h3...), not used for visual styling only.

Forms and Input Controls

• All form fields have associated <label> elements.
• Errors are programmatically associated with fields (ARIA aria-invalid, aria-described by) and error messages include suggestions to fix the problem.
• Use accessible date pickers and mask inputs only when accessible alternatives/labels are available.

Images, Icons and Media

• All informative images include meaningful alt text; purely decorative images use empty alt="".
• Complex images (diagrams) include long descriptions or downloadable accessible alternatives.
• Videos published by us include accurate captions and transcripts, where feasible we provide audio descriptions or sign-language interpretation for key videos.

Colour, Contrast and Typography

• Text contrast meets WCAG 2.2 AA minimums (at least 4.5:1 for normal text and 3:1 for large text).
• Avoid colour as the sole method of conveying information; support user’s system text-size and browser zoom (no horizontal scrolling up to 200% zoom).

Focus Management and Dynamic Content

• Single-page app behaviours and modal dialogs manage focus appropriately (trap focus inside modal, return focus after close).
• Use ARIA roles only where native semantics are insufficient and follow ARIA Authoring Practices. (W3C)

Accessible Documents and Downloads

• PDFs and downloadable documents are produced as accessible PDFs (tagged PDF, correct reading order, headings, proper alt text). If an accessible version is not available, we will provide one upon request.

Accessibility of Email and Marketing

• Marketing emails follow best practice for accessible HTML email (semantic structure, alt text, readable line lengths) and all programmatic newsletter content includes an accessible plain-text alternative.

Live Events and Hybrid Considerations

For Summit events (in-person/virtual), we commit to:

• Providing live captioning for major sessions where feasible.
• Providing transcripts for recorded sessions.
• Providing accessibility front-desk and support contact for venue accommodations and assistive devices.
• Sign language interpretation, large-print materials or one-to-one assistance where requested and practically possible.

4) Third-party Content and Limitations

We use third-party services (ticketing/payment providers, embedded videos, maps, analytics and sponsor widgets). These services set their own accessibility and privacy behaviour.

We:

• Configure third-party embeds to their most accessible settings when possible.
• Require major suppliers to demonstrate accessibility commitments in procurement and contracts (see Procurement section).
• Provide alternatives when third-party content is not accessible (e.g., accessible payment options, contact support).

Because we do not control all third-party code, some embedded content or vendor widgets may not fully meet WCAG – please report any problem and we will work with the supplier or provide an alternate path. Guidance on procurement and standards such as EN 301 549 and Section 508 informed how we manage third-party obligations. (ETSI)

5) Testing, Auditing and Quality Assurance (detailed plan)

We combine automated and manual testing to maximize coverage:

Automated Testing (continuous)

• Run CI tests using tools such as axe (Deque), Lighthouse, and WAVE for automated checks over each deployment and release.
• Maintain a cookie-free staging instance to allow automated crawlers to test entire site.

Manual Testing (regular schedule)

• Keyboard-only navigation testing across core flows (home → ticket purchase → KYC form → submission).
• Screen reader testing with NVDA (Windows) and VoiceOver (macOS/iOS). (Optional testing with JAWS where required).
• Mobile accessibility checks using TalkBack (Android) and VoiceOver (iOS).
• Colour contrast checks (tools and manual checks) plus colour-blindness simulations.

Real-World Testing and User Research

• Conduct periodic user testing sessions that include participants with diverse disabilities (visual, motor, cognitive, hearing) to validate flows and uncover barriers not detected by tools.
• Accessibility testing is scheduled before major releases and quarterly for the live site.

Audit Cadence and Reporting

• Full accessibility audit by external specialist at least annually (or after major redesigns).
• Internal accessibility regression tests run on every sprint and release.
• Publish an Accessibility Conformance Report (ACR) or executive summary after each major audit with remediation status. Reference guides and checklists used: WCAG 2.2 Understanding docs and WAI resources. (W3C)

6) Remediation and Roadmap

We prioritise fixes by user impact and severity (blocker → major → minor). Example target timelines once an accessibility issue is validated:

• Acknowledgement of user report: within 3 business days.
• Workaround or alternative provided (if applicable): within 7 business days.
• High-severity fix (site-blocking): aim to remediate within 30 calendar days.
• Medium/low severity: remediation included in upcoming sprint cycles; full resolution within 90 calendar days for medium and 180 days for low severity items where no regulatory deadline applies.

(These are target commitments; complex platform or third-party issues may require longer escalation and vendor remediation.) Use of formal timelines and response commitments follows best practice for accessibility statements. (W3C)

7) How to report Accessibility Issues (feedback process)

If you experience any issue, please provide:

1. The URL (web address) of the page with the problem.
2. A brief description of the issue (what you expected vs what happened).
3. The assistive technology / browser / device you used (e.g., NVDA + Firefox, VoiceOver + Safari on iPhone).
4. Any screenshots, screencasts, or sample files (if helpful).

Contact us: Support@SuperPlegSummit2026.com or (+91) 99641 83552. We will acknowledge receipt within 3 business days, provide a workaround if we can, and keep you updated on remediation. If we cannot resolve your complaint internally you may escalate to a relevant regulatory body (see “Regulatory compliance & legal” below). (W3C)

8) Conformance Claims and Reports

When we have completed an external audit, we will produce a public Accessibility Conformance Report (ACR) that documents:

• Which pages/areas were tested.
• The WCAG 2.2 success criteria tested and their conformance level.
• Testing tools and manual methods used.
• Known limitations and planned remediation steps and timelines.

You can request the most recent ACR by contacting Support@SuperPlegSummit2026.com.

9) Procurement, Suppliers and Accessibility Governance

We include accessibility requirements in procurement for ticketing, payment, verification (KYC), hosting, analytics and event platforms:

• Suppliers must declare their accessibility conformance and provide test evidence (WCAG reports or EN 301 549/Section 508 evidence) during procurement. (ETSI)
• Contracts require reasonable cooperation on remediation and accessible configurations.

Internally:

• Assign an Accessibility Owner (e.g., Product/Engineering lead) responsible for coordinating audits, vendor remediation, and reporting.
• Provide regular accessibility training for designers, developers and content authors (semantic HTML, ARIA best practice, captioning, accessible PDF authoring). WAI-ARIA Authoring Practices is the foundation for widget design. (W3C)

10) Staff training & content governance

We run recurring training for:

• Content authors – how to write accessible headings, alt text, link text, and how to create accessible PDF/PowerPoint.
• Designers – colour contrast, focus states, accessible components and motion reduction.
• Developers – semantic HTML, ARIA (use only when necessary), keyboard handling, focus management and accessible testing tools.

Guidance references: WAI authoring practices, W3C Understanding documents, and practical checklists based on WCAG 2.2. (W3C)

11) Accessible Documents, Downloads, and Transcripts

• All new PDFs and downloadable documents will be created as tagged accessible PDFs with correct reading order, structural headings, and searchable text.
• For legacy PDFs we commit to provide an accessible alternative upon request.
• All recorded video content will have captions and a transcript published; where feasible, provide audio description or sign language for key sessions/materials.

12) Technical Requirements and Developer Checklist

Use this checklist for engineering or third-party vendors:

1. Semantic HTML: Correct roles, headings, list semantics.
2. Navigation: Skip link, landmarks, logical tab order.
3. Colour contrast: Meet WCAG 2.2 AA ratios (4.5:1 normal text).
4. Focus: visible, not removed by CSS; Manage focus after DOM updates/modals.
5. Media: Captions, transcripts; accessible controls (keyboard operable).
6. ARIA: Use only when native elements insufficient; follow APG patterns. (W3C)
7. Forms: Labels, error programmatic association, accessible form controls.
8. Images: Alt text and long descriptions for complex images.
9. Documents: Produce tagged, accessible PDFs.
10. Testing: Axe/Lighthouse scans + manual NVDA/VoiceOver keyboard tests.
11. Mobile: Responsive layout, accessible touch targets (minimum 44×44 CSS px recommended), and Zoom support.
12. Avoid content that flashes above thresholds that cause seizures.

13) Tools we use / Recommended Tools for Audits

• Automated: Axe Core/CLI, Lighthouse (Chrome devtools), WAVE, Pa11y.
• Manual: NVDA (Windows), VoiceOver (macOS/iOS), TalkBack (Android), keyboard-only navigation.
• Contrast and Simulation: Colour Contrast Analyser, colour blindness simulators.
• Document Checks: Adobe Acrobat Accessibility Checker for tagged PDFs.
• User Research: Moderated usability tests with participants using assistive tech.

(These tools help detect many but not all issues – manual testing and user testing are essential.) (W3C)

14) Legal and Regulatory Compliance

We use WCAG 2.2 AA as the technical standard and consider regional laws and guidance when relevant (for example Section 508 for U.S. federal procurement, EN 301 549 for EU public procurement). Where legal obligations mandate different wording or additional processes (e.g., EU Web Accessibility Directive or domestic public sector laws) we will publish an updated conformance statement. (Section508.gov)

15) Example “known issues” section

When you publish the accessibility page you may include a “Known Issues” list that is short, honest and actionable. Example entries:

• “Third-party embedded map widget (Vendor X) currently does not expose a keyboard focusable control for map panning — workaround: contact our support team to book assistance for mapping queries. Target remediation: vendor configuration/patch within 90 days.”
• “Some legacy PDFs uploaded before Oct 1, 2025 are not fully tagged – request an accessible copy via Support@SuperPlegSummit2026.com. Remediation target: re-publish accessible PDFs within 60 days of request.”

Include a date for each entry and a status (reported / acknowledged / in remediation / resolved).

16) Accessibility Conformance

“This website is being developed to conform to WCAG 2.2 Level AA. We are performing automated and manual accessibility testing, and we publish remediation progress in our Accessibility Conformance Reports. If you have difficulty using the site, or require content in an alternative format, contact Support@SuperPlegSummit2026.com. We will acknowledge your message within 3 business days and provide a response or workaround.”

Cite WCAG reference on the page (link to W3C WCAG 2.2) and to guidance for accessibility statements. (W3C)

17) Sample Accessible Content Authorship Rules

• Use descriptive link text (avoid “click here”).
• Keep headings brief and hierarchical.
• Provide alt text for images and long descriptions for complex diagrams.
• Use simple language for body copy where possible; provide glossary for specialised terms.
• For forms, provide inline help and ARIA aria-describedby for instructions.
• Avoid auto-playing audio or video; allow users to pause/stop/mute.

18) Implementation Roadmap

• Month 0–1: Run full automated scan and baseline audit. Publish this accessibility statement and initial “known issues” with contact details.
• Month 1–3: Triage top 30 critical issues; implement keyboard and focus fixes; ensure checkout and KYC forms accessible. Start manual screen reader testing for critical user journeys.
• Month 3–6: Remediate medium severity issues; convert the most used PDFs to accessible formats; set up continuous integration automated tests. Run user testing with participants with disabilities.
• Ongoing: Quarterly audits, annual external audit, ongoing vendor procurement checks and staff training.

19) Contact, Feedback and Escalation

If you find an accessibility issue or need content in a different format, please contact:

• Email: Support@SuperPlegSummit2026.com
• Phone: (+91) 99641 83552
• Address: The Address will be updated soon. Right now, it is Aundh, Pune. Your Purchase Confirmation or Account Dashboard will include the Official Address when published.

When reporting, include URL, a description of the issue, device/assistive tech used, and any attachments that help illustrate the problem. We will acknowledge within 3 business days and provide a workaround or update.

If you are not satisfied with our response, you may escalate the complaint to a relevant authority in your jurisdiction (for example, supervisory authorities under local accessibility law). We will cooperate with official investigations as required by law. Guidance on developing statements and required content informed our processes. (W3C)