Skip to content

Use of Standards

Jump to bottom
Ebubekir Erden edited this page Apr 16, 2026 · 3 revisions

This document outlines the core industry standards adopted across our web, mobile, and backend architectures to ensure accessibility, interoperability, security, and maintainability for our mentorship platform.

1. Web Content Accessibility Guidelines (WCAG) 2.1 Level AA

  • Standard Selected: W3C WCAG 2.1 Level AA.
  • Why we chose it: The platform must be inclusive and fully functional for all users, including those using assistive technologies. Level AA is the global legal and industry baseline for commercial and educational software.
  • How we plan to integrate it:
    • React (Web): Utilizing eslint-plugin-jsx-a11y to fail builds if semantic HTML constraints (e.g., missing alt tags, improper ARIA roles) are violated.
    • React Native (Mobile): Implementing native accessibility bridges using accessibilityRole and accessibilityLabel for iOS VoiceOver and Android TalkBack compatibility.
    • Tailwind CSS: Enforcing a minimum 4.5:1 text-to-background contrast ratio in the Tailwind config and utilizing focus-visible variants for clear keyboard navigation paths.

2. Web Semantics and Interactivity (W3C DOM & WAI-ARIA)

  • Standard Selected: W3C HTML5 Semantic DOM and WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) 1.2.

  • Why we chose it: Semantic HTML improves SEO and machine readability. ARIA bridges the gap where native HTML falls short in complex Single-Page Applications (SPAs).

  • Also The World Wide Web Consortium (W3C) is essentially unescapable in modern web development, as it defines the fundamental building blocks of the web itself. Core concepts such as semantic HTML, the CSS box and layout models, and the Document Object Model (DOM) are all formal W3C standards. These are not optional features but the very mechanisms that enable structure, styling, and interactivity in our application. Their standardization ensures consistency across browsers, making them both indispensable and highly effective foundations for building robust and scalable web systems.

  • How we plan to integrate it:

    • Semantic HTML Usage: Using structural tags (<main>, <nav>, <article>, <section>) instead of generic <div> containers in our React components to provide meaningful document structure for both browsers and assistive technologies.

    • DOM-Based Interactivity: Leveraging the DOM indirectly through React’s Virtual DOM to efficiently update UI components, manage user interactions (clicks, inputs), and ensure responsive and dynamic page behavior.

    • ARIA for Accessibility: Applying dynamic ARIA attributes (e.g., aria-expanded, aria-hidden, aria-live) for custom components like dropdowns, modals, and tabs to communicate state changes to screen readers.

    • CSS Box & Layout Model Compliance: Designing layouts using Tailwind CSS utilities that align with the W3C CSS box model (margin, border, padding, content) and modern layout systems (Flexbox, Grid) to ensure consistent rendering across different screen sizes and browsers.

    • Event Handling Standards: Utilizing standardized DOM event mechanisms (e.g., onClick, onChange) within React to ensure predictable and consistent interaction behavior across platforms.

3. Structured Data (JSON-LD & Schema.org)

  • Standard Selected: Schema.org vocabularies formatted via W3C JSON-LD (JavaScript Object Notation for Linked Data).
  • Why we chose it: Schema.org provides the standard vocabulary to describe our content, while JSON-LD provides the cleanest syntax to embed it without cluttering UI code. This ensures search engines can accurately index our public-facing content.
  • How we plan to integrate it:
    • Frontend Injection: Injecting <script type="application/ld+json"> blocks dynamically into the <head> of public pages using React Helmet or a similar document head manager.
    • Vocabularies: We will utilize specific Schema.org types such as Person (for mentor profiles), EducationalOrganization (for platform data), and Event (for public webinars or group sessions).

4. API Architecture (REST & OpenAPI)

  • Standard Selected: RESTful HTTP/1.1 Constraints and the OpenAPI Specification (OAS) 3.0.
  • Why we chose it: REST provides a predictable contract between frontend interfaces and the backend database. OpenAPI provides a machine-readable standard for documenting these APIs, reducing friction between backend (Django) and frontend (React/React Native) teams.
  • How we plan to integrate it:
    • Django Backend: Strict mapping of CRUD operations to HTTP methods (GET, POST, PATCH, DELETE) with standard HTTP status codes.
    • Documentation: Using drf-spectacular in Django to automatically generate an OpenAPI schema, which will render an interactive Swagger UI for developers to test endpoints.

5. Authentication & Authorization (JWT & OAuth 2.0)

  • Standard Selected: IETF RFC 7519 (JSON Web Tokens) and RFC 6749 (OAuth 2.0).
  • Why we chose it: Given our decoupled architecture (React Web + Expo Mobile), JWT provides a stateless, scalable, and standardized method for securely transmitting user sessions across different platforms.
  • How we plan to integrate it:
    • Django Backend: Utilizing Django REST Framework (DRF) JWT libraries (like djangorestframework-simplejwt) to issue signed access and refresh tokens.
    • Client Applications: Storing tokens securely and appending them to the Authorization: Bearer <token> header for all protected requests.

6. Date and Time Data (ISO 8601)

  • Standard Selected: ISO 8601 (Data elements and interchange formats – Information interchange – Representation of dates and times).
  • Why we chose it: Mentorship involves scheduling sessions across multiple global time zones. Relying on local time formats in the database or API causes critical scheduling bugs.
  • How we plan to integrate it:
    • Backend Storage: Django/PostgreSQL will store all timestamps in UTC.
    • API Transmission: All date/time data sent over the API will be strictly formatted as ISO 8601 strings (e.g., 2026-04-16T14:30:00Z).
    • Frontend Display: The frontend will parse the ISO 8601 string and localize it to the user's current device timezone using standard JavaScript Intl.DateTimeFormat or libraries like date-fns.

7. Programming Language Formatting Standards

  • Standard Selected: PEP 8 (Python) and ECMAScript (JavaScript/TypeScript).
  • Why we chose it: Adhering to the official style guides of our respective languages ensures code consistency, reduces cognitive load during code reviews, and prevents bugs.
  • How we plan to integrate it:
    • Django (Python): Enforcing PEP 8 standards using Flake8 and Black in our pre-commit hooks and CI/CD pipelines.
    • React/Mobile (TypeScript): Enforcing ECMAScript conventions and strict type checking using ESLint and Prettier, catching syntax and style errors before code is pushed.

Links: Home | Main Repository

Team Members

Requirements & Design

Milestones & Deliverables

Final Milestone (1.0.0)

Final Release Reports

Milestone 2 (0.2.0-alpha)

MVP Milestone (0.1.0-alpha)

Project Documentation

Meetings & Reports

Weekly Meetings

View List

Customer & Stakeholder Meetings

Other Meetings

Lab Reports

View List

Templates

Clone this wiki locally