Accessibility Statement

Commitment

DeshiAI is committed to making its reporting, analysis, editorial policies, forms and digital services accessible to people with diverse visual, auditory, physical, speech, cognitive, language, learning and neurological needs. Accessibility is treated as an important part of editorial quality, technical reliability and responsible digital publishing.

The objective is not simply to make information technically available. DeshiAI aims to enable people to perceive, understand, navigate and interact with its website using different devices, input methods, assistive technologies, browser settings and reading preferences.

Accessibility Standard and Status

DeshiAI is working toward conformance with the Web Content Accessibility Guidelines 2.2 at Level AA. This is an ongoing accessibility target and implementation standard. The website has not yet completed a comprehensive independent conformance assessment, and DeshiAI therefore does not claim full or formal conformance. The status described on this page will be revised only when documented evaluation of the website, templates, navigation, forms, consent interface, articles, multimedia, documents and relevant third-party components supports a change.

At the public launch stage, DeshiAI describes its status as partially conformant with WCAG 2.2 Level AA. Partial conformance means that some areas of the website may not yet satisfy every applicable accessibility requirement. This statement will be changed only when documented testing or assessment supports a different position. Automated scanning alone is not considered evidence of complete conformance.

Scope

This statement applies to public content and functionality controlled by DeshiAI on its principal website, including the homepage, technology and AI articles, subject archives, author information, policy pages, contact pages, correction routes, contributor information, commercial disclosures, navigation, search, cookie controls, newsletter forms, images, audio, video, downloadable documents and other core interfaces.

Third-party websites linked from DeshiAI are outside DeshiAI’s direct control. Embedded third-party services may also introduce accessibility limitations that the publication can influence only partially. Where practical, DeshiAI seeks accessible alternatives, configuration changes or replacement options when a third-party component creates a significant barrier.

Accessibility Principles

DeshiAI aims to make information perceivable, functionality operable, content understandable and implementation robust. Information should be available in forms users can perceive, including appropriate text alternatives and captions. Navigation and controls should work with different input methods. Articles and forms should use clear structure, predictable behaviour and understandable instructions. Standards-based markup is used to support current browsers and assistive technologies as reasonably possible.

Keyboard Access and Focus

Essential functions are designed to be usable through a keyboard without requiring a mouse or touchscreen. This includes navigation, mobile menus, search, links, buttons, forms, cookie settings, media controls, accordions, modal dialogs and error recovery. Keyboard focus should remain visible, move through controls in a logical sequence and not become trapped inside a component without a clear way to exit.

Skip Navigation and Landmarks

Pages provide a working skip-to-content mechanism intended to allow keyboard and assistive-technology users to bypass repeated navigation. The link becomes visible when focused, moves focus toward the main content and is intended to remain usable across relevant templates and fixed interface elements.

Core page regions are identified using appropriate structural markup, including header, navigation, main content, complementary material, search and footer. Repeated regions receive clear labels where necessary, and page titles are intended to describe the content accurately.

Heading Structure and Language

Pages use headings according to document structure rather than visual styling alone. The main article title normally serves as the principal page heading, with subheadings following a logical hierarchy. Heading elements are not used simply to make text appear larger.

The primary language of a page is identified where technically appropriate. Passages written in another language may be marked accordingly. Translated content should preserve the intended meaning and receive appropriate review where accuracy is important to the subject matter.

Text, Readability and Reflow

DeshiAI aims to use readable text sizes, sufficient line spacing, reasonable line lengths, clear paragraph structure, meaningful headings, explained abbreviations, plain language where practical, appropriate technical terminology, adequate spacing between controls and layouts that remain usable when text is enlarged. Accessibility does not require reducing the depth of AI or technology reporting; it requires reducing avoidable barriers to understanding and use.

Core content is intended to remain readable and operable when users enlarge text or zoom. At 200 percent zoom, DeshiAI seeks to avoid clipped text, overlapping controls, hidden content, inaccessible navigation, missing form labels, unnecessary horizontal scrolling for ordinary text and unreachable controls. Higher magnification and responsive reflow are considered where technically practical.

Contrast and Color

Text and important interface components should have sufficient contrast against their backgrounds. Review may include body text, headings, navigation, links, buttons, form borders, error messages, focus indicators, cookie controls, disabled states, image text, sponsored labels and correction notices. Color is not intended to be the sole method of communicating status, error, category or disclosure.

Links, Buttons and Controls

Link text should communicate the destination or purpose. Ambiguous phrases such as “click here” or “read more” are avoided where the surrounding context does not provide a sufficiently clear accessible name. Repeated links within article cards should provide enough information to identify the relevant article. Links should be distinguishable from ordinary text.

Buttons should have understandable labels and predictable behaviour. Icon-only controls should have accessible names, and controls should not depend solely on an icon, colour, position, shape or hover state. Touch targets should remain usable, and controls should not move unexpectedly while a person is attempting to activate them.

Forms

Forms provide visible and programmatic labels, clear instructions, required-field identification, understandable validation, useful error messages, correction guidance, logical focus order, keyboard operation, accessible confirmation, privacy information, appropriate autocomplete and sufficient time. Accidental loss of entered information is avoided where practical. Placeholder text does not replace a persistent form label.

Contact, correction, complaint, contributor, privacy and accessibility routes should collect only information necessary for the specific purpose. They should not unnecessarily require medical diagnoses, identity documents, home addresses, telephone numbers, organizational details, demographic information or sensitive evidence. An email alternative remains available where a form itself creates an accessibility barrier.

Cookie Controls

Cookie controls are intended to support keyboard operation, visible focus, understandable category descriptions, accessible toggles, screen-reader announcements, comparable access to acceptance and rejection options, persistent settings, clear confirmation, zoom and mobile use. The consent interface should not trap focus or unnecessarily prevent access to essential information.

Images and Alternative Text

Informative images should have meaningful alternative text that communicates their purpose within the article rather than repeating a filename or inserting keywords. Decorative images should be identified so assistive technologies can ignore them. Alternative text should not infer emotion, motive, guilt or identity without evidence and should not contain promotional keyword stuffing or unsupported claims.

Editorial photographs should identify relevant people where appropriate, describe significant action or setting, include visible text where material and distinguish documentary images from illustrations where necessary. Complex images should receive a longer textual explanation when concise alternative text cannot communicate the essential information.

Charts, Graphs, Tables and Infographics

Charts and infographics should provide an accessible equivalent sufficient to understand their essential information, such as a text summary, underlying data table, trend description, values, categories, source, methodology and relevant limitations. Colour alone should not distinguish data series, and labels should remain understandable when enlarged.

Data tables should use appropriate headers, row and column associations, captions, simple structures, responsive presentation and textual explanation where complexity is significant. Tables should not be used merely for visual layout. On smaller screens, information should remain understandable through scrolling, reformatting or another appropriate presentation.

Audio and Video

Audio content should provide a transcript where necessary to access its substantive information. Transcripts should identify speakers and relevant non-speech sound and should indicate uncertainty or translation where appropriate. Video should provide synchronized captions, transcripts, audio description or descriptive narration as appropriate, together with accessible controls, keyboard operation and user control over playback. Captions should be reviewed for material accuracy, particularly for names, technical terminology, accents and other languages.

Live content may require live captions, interpretation, accessible presentation materials, advance information, participation alternatives and a transcript or recording after the event. Available support should be disclosed before registration where practical, and DeshiAI does not promise accessibility services that have not been arranged.

Motion, Flashing and Autoplay

Content should avoid flashing that could create a safety risk. Animation, carousels, auto-updating regions and other moving elements should provide controls where necessary. Users should be able to pause, stop or hide non-essential moving content that begins automatically and persists. Reduced-motion preferences are respected where technically possible. Audio does not play automatically, while auto-playing video should be muted by default and should not interfere with reading or keyboard focus.

Documents and Downloads

Downloadable documents should be made accessible where reasonably possible, including through semantic headings, logical reading order, tagged structure, searchable text, table headers, meaningful links, alternative text, language information, document titles, bookmarks for longer documents, sufficient contrast and accessible forms. Scanned image-only PDFs should be avoided where accessible HTML or a properly structured document can be provided.

Where an inaccessible legacy document must remain available, DeshiAI may provide an accessible summary or alternative upon request where practical. Before publishing a PDF or Word document, the publication considers whether HTML would provide better access and whether the export process has preserved headings, reading order, links, tables and image descriptions.

Mobile and Assistive Technology Testing

Core tasks are tested on mobile devices where practical, including menus, search, article reading, forms, cookie controls, zoom, orientation, touch targets, sticky elements, advertising, image scaling, tables and video. Content should not require a particular screen orientation unless that orientation is essential to the function.

DeshiAI combines automated checks with keyboard-only testing, zoom and reflow testing, contrast checks, screen-reader testing, form testing, mobile testing, document review, manual semantic review, third-party component review and user feedback. Automated tools can identify certain defects but cannot establish complete accessibility, compatibility or usability on their own.

Third-Party Components

Third-party services may include video players, advertising systems, analytics, consent platforms, social embeds, maps, forms, newsletter tools, payment services, fonts, security challenges and document viewers. DeshiAI considers accessibility before deploying or materially changing these components. Where a component creates a barrier, possible responses include configuration changes, an accessible alternative, direct access to content, a transcript, removal, replacement, vendor escalation, limitation, warning or temporary workaround.

Known Limitations

At launch, potential limitations may include older articles awaiting complete accessibility review, legacy images without full alternative text, inconsistent heading structures, third-party embeds, older downloadable documents, template-generated duplicate elements, cookie-interface behaviour, mobile navigation, form validation, table responsiveness and automatic caption errors. Only limitations actually identified are retained on the public statement, and resolved issues are removed after appropriate verification.

Accessibility of Commercial and Accountability Content

Advertising, sponsored content and partner material are expected to follow the same accessibility principles as independent editorial material. Commercial disclosures should be visible, readable, programmatically available and not dependent solely on colour. DeshiAI may reject or remove advertising that creates a material accessibility barrier.

Correction, clarification, update, retraction and commercial-disclosure notices should be prominent, available to assistive technologies, structured as text and understandable without relying solely on colour or an icon.

Testing Frequency and Procurement

Accessibility is reviewed before a material feature or template is released, after significant design, theme or extension changes, after introducing new forms, consent tools, media players or community features, following a significant accessibility complaint, after major content migration and periodically as part of website maintenance. Critical barriers affecting core content or contact routes receive priority.

Accessibility is also considered when selecting themes, extensions, form providers, video players, consent platforms, advertising systems, analytics tools, newsletter services, document workflows, payment services, community platforms and external contractors. Vendor accessibility claims do not replace practical testing.

Feedback and Alternative Access

Anyone who encounters an accessibility barrier may contact DeshiAI through contact@deshiai.in and identify the affected page, barrier encountered, action attempted, device, browser, operating system, assistive technology where relevant, screenshot where useful and preferred accessible format. A person does not need to disclose a diagnosis, medical condition or medical record to report an accessibility issue.

DeshiAI aims to acknowledge a specific accessibility report within five business days. A straightforward issue may be resolved quickly, while a theme, extension, document or third-party limitation may require additional time. Where immediate remediation is not possible, DeshiAI may consider a plain-text version, accessible document, transcript, data table, email copy, accessible summary, image description, alternative form, human assistance or another substantially equivalent format.

Complaints, Records and Review

A person dissatisfied with the handling of an accessibility issue may submit a formal complaint through contact@deshiai.in, clearly identifying the matter as an accessibility complaint. Applicable law may provide an external complaint route depending on the person’s jurisdiction and the nature of the service.

DeshiAI may maintain proportionate records of accessibility audits, reported issues, severity, affected pages, responsible owners, workarounds, remediation, retesting, user feedback, third-party limitations and completion dates. Significant progress and unresolved barriers may be summarized through DeshiAI’s broader editorial transparency practices.

DeshiAI does not retaliate against a person for providing critical accessibility feedback. Abusive communication may be limited where necessary, but a genuine accessibility concern will still be assessed where reasonably possible.