Semantic Structure & Landmarks
Built on clean HTML5 semantic landmarks (header, nav, main, section, footer) with correct heading nesting (h1–h4) and an immediate “Skip to main content” link.
Accessibility & Inclusion
Dotnitron is committed to universal digital accessibility across our public platforms, enterprise AI interfaces, and forward-deployed client solutions. This statement and VPAT document our conformance with WCAG 2.1 Level AA and Section 508 standards.
Dotnitron Technologies Private Limited engineers forward-deployed AI systems, automated workpaper tools, and specialized software for institutional clients across banking, private equity, insurance, investment advisory, and corporate operations. We believe enterprise software and AI systems must be inherently accessible, transparent, and usable for professionals of all abilities.
Our accessibility programme encompasses both our public digital presence and our engineering delivery practices:
We design, evaluate, and audit our web applications and client interfaces against the following recognized standards:
Built on clean HTML5 semantic landmarks (header, nav, main, section, footer) with correct heading nesting (h1–h4) and an immediate “Skip to main content” link.
All interactive controls are accessible via keyboard alone without traps. A visible high-contrast focus indicator confirms active element location at all times.
Color contrast ratios exceed the 4.5:1 standard for normal text and 3:1 for large text across both dark and light color modes. Color is never the sole conveyor of information.
Respects operating system prefers-reduced-motion preferences to disable decorative animations. Tested with modern screen readers (VoiceOver, NVDA) and keyboard navigation.
Enterprise AI deliverables (due diligence tables, audit workpapers, evidence reconciliations) use accessible data table structures with explicit row/column headers rather than inaccessible static canvases.
Asynchronous AI workflows, streaming analysis, and background verification queues communicate state changes via polite ARIA live regions without interrupting user screen-reader navigation.
Product: Dotnitron Web Platform & UI Design System (v1.0) · Report Date: November 2026 · Format: VPAT Version 2.5 (WCAG Edition).
Evaluation Methods: Automated static evaluation (axe-core, Lighthouse), manual keyboard-only navigation audits, screen reader evaluation (macOS VoiceOver / Safari), and color contrast analysis.
| Criterion | Level | Conformance | Remarks & Explanations |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Supports | All meaningful images, icons, and partner marks provide descriptive text alternatives (alt attributes). Decorative graphics and ambient gradients use aria-hidden="true". |
| 1.2.1 - 1.2.5 Time-based Media (Audio / Video) | A / AA | Not Applicable | The public website does not host pre-recorded audio-only, video-only, or synchronized multimedia content requiring captions, audio descriptions, or live subtitles. |
| 1.3.1 Info and Relationships | A | Supports | Semantic HTML5 elements (header, nav, main, section, article, footer) define page landmarks. Heading hierarchies (h1–h4) and list structures are logically ordered. |
| 1.3.2 Meaningful Sequence | A | Supports | DOM reading order matches the visual reading order. CSS flexbox and grid layouts preserve logical information sequencing for screen readers. |
| 1.3.3 Sensory Characteristics | A | Supports | Instructions do not rely solely on sensory characteristics such as shape, color, size, visual location, or sound to convey meaning. |
| 1.3.4 Orientation | AA | Supports | Content display does not restrict its view and operation to a single display orientation (portrait or landscape). |
| 1.3.5 Identify Input Purpose | AA | Supports | Contact form fields utilize standard autocomplete and input types (name, email, company, message) enabling assistive technology recognition. |
| 1.4.1 Use of Color | A | Supports | Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. |
| 1.4.3 Contrast (Minimum) | AA | Supports | Body text maintains at least a 4.5:1 contrast ratio against backgrounds. Large text (18pt+ or 14pt+ bold) maintains at least 3:1 contrast across both light and dark themes. |
| 1.4.4 Resize Text | AA | Supports | Text can be resized up to 200 percent using standard browser zoom controls without loss of content, structure, or functionality. |
| 1.4.5 Images of Text | AA | Supports | Real HTML text styled with CSS is used across all content. Images of text are avoided except for third-party registered trademarks and logos. |
| 1.4.10 Reflow | AA | Supports | Pages reflow to a 320 CSS pixel width without horizontal scrolling or loss of content and functionality. |
| 1.4.11 Non-text Contrast | AA | Supports | Visual boundaries of active UI components, buttons, inputs, and focus rings provide at least a 3:1 contrast ratio against adjacent colors. |
| 1.4.12 Text Spacing | AA | Supports | Content accommodates overrides for line height, letter spacing, word spacing, and paragraph spacing without clipping or overlap. |
| 1.4.13 Content on Hover or Focus | AA | Supports | Interactive tooltips or overlays triggered by pointer hover or keyboard focus are dismissable without moving the pointer and remain persistent until dismissed. |
| Criterion | Level | Conformance | Remarks & Explanations |
|---|---|---|---|
| 2.1.1 Keyboard | A | Supports | All interactive components—including navigation links, menus, form controls, and theme toggles—are fully operable via standard keyboard interfaces. |
| 2.1.2 No Keyboard Trap | A | Supports | There are no keyboard traps. Focus can be moved away from any focused component using standard keyboard keys (Tab, Shift+Tab, Escape). |
| 2.1.4 Character Key Shortcuts | A | Not Applicable | The website does not implement single-character keyboard shortcuts that could interfere with speech-input or assistive software. |
| 2.2.1 Timing Adjustable | A | Not Applicable | No time limits are imposed on reading content or completing forms on the public website. |
| 2.2.2 Pause, Stop, Hide | A | Supports | Any automated animations respect prefers-reduced-motion settings. No auto-advancing carousels or unpausable background motion exist on the site. |
| 2.3.1 Three Flashes or Below Threshold | A | Supports | No content flashes more than three times in any one-second period, preventing photo-epileptic seizures. |
| 2.4.1 Bypass Blocks | A | Supports | A visible-on-focus 'Skip to main content' link is provided at the very top of the DOM, allowing keyboard users to bypass repetitive header navigation. |
| 2.4.2 Page Titled | A | Supports | Each page includes a unique, descriptive <title> element communicating the topic, service, or article and branding. |
| 2.4.3 Focus Order | A | Supports | Keyboard navigation follows a logical, sequential focus order aligned with the visual reading hierarchy. |
| 2.4.4 Link Purpose (In Context) | A | Supports | The purpose of every hyperlink is clear from the link text alone or from its immediate surrounding programmatic context. |
| 2.4.5 Multiple Ways | AA | Supports | Users can locate pages via multiple mechanisms: primary navigation menus, categorised footer sitemaps, internal content cross-links, and the public sitemap.xml. |
| 2.4.6 Headings and Labels | AA | Supports | Headings and form labels clearly describe the topic, purpose, or requested information. |
| 2.4.7 Focus Visible | AA | Supports | A high-contrast focus ring (outline / ring) is visually apparent on all interactive controls during keyboard navigation. |
| 2.5.1 - 2.5.4 Pointer Gestures, Target Size & Cancellation | A / AA | Supports | All functionality can be operated with single-pointer gestures without multipoint or path-based gestures. Interactive touch targets meet recommended minimum sizes (at least 24×24px with adequate spacing), and click actions trigger on up-event allowing cancellation. |
| Criterion | Level | Conformance | Remarks & Explanations |
|---|---|---|---|
| 3.1.1 Language of Page | A | Supports | The default natural language of each page is programmatically determined via the lang="en" attribute on the <html> element. |
| 3.1.2 Language of Parts | AA | Supports | All content is authored in English. Any future non-English passages will include inline lang attributes. |
| 3.2.1 - 3.2.2 On Focus & On Input | A | Supports | Receiving focus or entering input does not initiate unexpected context changes (such as automatic form submission or unexpected navigation). |
| 3.2.3 Consistent Navigation | AA | Supports | Navigation mechanisms (header, footer, submenus) appear in the same relative order and structure across all pages. |
| 3.2.4 Consistent Identification | AA | Supports | Components with the same functionality (buttons, search links, status badges) are identified consistently across the site. |
| 3.3.1 - 3.3.2 Error Identification & Labels | A | Supports | Form fields include visible text labels and clear programmatic descriptions. Input errors are identified in text with guidance on resolution. |
| 3.3.3 - 3.3.4 Error Suggestion & Prevention | AA | Supports | Where input errors are detected, suggestions for correction are provided. Submissions allow review prior to final action. |
| Criterion | Level | Conformance | Remarks & Explanations |
|---|---|---|---|
| 4.1.1 Parsing | A | Supports | HTML markup is validated for correct syntax: elements have complete start and end tags, elements are nested according to specification, and IDs are unique. |
| 4.1.2 Name, Role, Value | A | Supports | Standard HTML5 elements are used for all interactive UI controls. Custom controls (such as the theme toggle and cookie consent banner) use appropriate ARIA attributes (e.g., aria-expanded, aria-label, role="dialog"). |
| 4.1.3 Status Messages | AA | Supports | Status updates and submission confirmations are conveyed programmatically to assistive technologies using ARIA live regions or alert roles without requiring focus shifts. |
Procurement teams can also request or review the plain-text/raw VPAT report at /docs/vpat-dotnitron-wcag-2.1-aa.txt.
We continually audit our software and marketing assets. In the spirit of transparent compliance:
We welcome feedback from users, customers, and accessibility specialists. If you encounter an accessibility barrier or require content in an alternative accessible format, please contact us:
Dotnitron Accessibility & Governance Team
Email: info@dotnitron.com (Subject: [Accessibility Feedback])
We aim to respond to all accessibility inquiries within 2 business days with an accessible solution, alternative format, or remediation timeline.