WC3 Standards - bounswe/bounswe2025group5 GitHub Wiki

WC3 Standards

1. Web Content Accessibility Guidelines (WCAG) 2.1 AA

The Web Content Accessibility Guidelines (WCAG) is an international standard developed by World Wide Web Consortium (W3C) to achieve a single shared standard for web content accessibility. It aims to ensure that web content is accessible for people with disabilities. The guidlines is for the need of individuals, developers, and international governments. WCAG 2.1 was published on 5 June 2018 and updated lastly on 6 May 2025. For each guideline there are three levels success criteria of success criteria: A, AA, and AAA. AA criteria is the recommended standard for most websites.

Possible Additions to the Requirements:

Requirement WCAG 2.1 Standard
2.1.2 Usability Requirements
2.1.2.4 All non-text content (images, icons, charts) shall have meaningful text alternative or label. 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
2.1.2.5 Minimum color contrast ratio of 4.5:1 for text and 3:1 for large text/UI shall be maintained. 1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 and large-scale text and images of large-scale text have a contrast ratio of at least 3:1.
2.1.2.6 Interactive elements shall be fully operable via keyboard. 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
2.1.2.7 Visible focus indicators for all interactive elements (keyboard, mouse etc.) shall be provided for all interactive elements. 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
2.1.2.8 Navigational components shall be placed consistently through web pages. 3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.
2.4 Portability & Compatibility Requirements
2.4.3 The platform shall support screen readers such as NonVisual Desktop Access (NVDA) and VoiceOver. 4.1.2 Name, Role, Value: For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
2.4.4 The platform shall support text resizing up to 200% without loss of content or functionality. 1.4.4 Resize Text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Referance:

2. Activity Streams 2.0

Activity Streams 2.0 (AS2.0) is a W3C standard for describing social and user-driven actions in a consistent, machine-readable format.
It provides a simple data model for capturing who did what, to what, and when — for example, a user liking a post, creating content, or joining a challenge.

🔑 Core Concepts

  • Actor → the entity performing the action (e.g., a user).
  • Activity → the action being performed (e.g., Like, Create, Join).
  • Object → the target of the action (e.g., a post, challenge, or badge).
  • Resulting Context → optional, like the collection or feed where the action belongs.

🧩 Example Activities

Like a Post

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Like",
  "actor": "https://example.com/users/u123",
  "object": "https://example.com/posts/p456"
}

Comment on a Post

{
  "type": "Create",
  "actor": "https://example.com/users/u123",
  "object": {
    "type": "Note",
    "content": "This is my comment",
    "inReplyTo": "https://example.com/posts/p456"
  }
}

⚡ Why It Matters for Us

  • Consistency → Instead of handling likes, comments, shares, and saves separately, we can treat them all as Activities.
  • Interoperability → Using a standard format means our data model aligns with other platforms (like Mastodon, ActivityPub).
  • Extensibility → Easy to define custom activities (e.g., LogWaste, EarnBadge) without redesigning the system.
  • Future-proofing → Opens doors for features like activity feeds, external integrations, and richer analytics.

📝 Relevance to Our App

Our app already includes user actions that map directly to Activity Streams 2.0 concepts:

App Concept Glossary Term / Requirement AS2.0 Mapping
Create a post Post (1.1.4.1) Create (object = Note)
Like a post Like Post (1.1.4.6) Like
Comment on a post Comment (1.1.4.7) Create (object = Note, with inReplyTo)
Share a post Share (1.1.4.8) Announce
Save a post Save (1.1.4.5) Add (target = Saved items)
Join a challenge Community Sustainability Challenge (1.1.3.1) Join
Log waste Waste Log (1.1.2.1) Create (custom type = WasteLog)
Earn achievement badge Achievement Badge (1.2.3.2, 1.2.3.6) Achieve (custom)
Redeem eco-friendly reward Eco-friendly Reward (1.1.5.3) Consume or custom

⚙️ Potential Changes and Future Considerations for Adaptation

As part of adopting Activity Streams 2.0, several potential changes and enhancements to the system have been identified to make the app more standardized, consistent, and future-proof:

  • Standardized Activity Modeling:
    Existing user actions—such as creating posts, liking, commenting, sharing, saving, joining challenges, logging waste, and earning badges—can be represented consistently as standardized activities. This provides a unified structure for tracking, storing, and analyzing interactions, and ensures that all activities are compatible with Activity Streams 2.0.

  • Additions to Requirements:
    To comply with standards, a new section under system requirements (e.g., 1.2.6 Standardization Requirements) should be added, stating that all user interactions should be represented using a standardized activity formats. Here is the suggested section:

1.2.6 Standardization Requirements

1.2.6.1 The system shall model user interactions (e.g., Like, Comment, Share, Save, Join Challenge) using standardized vocabularies and data formats.
1.2.6.2 In particular, the system shall represent user actions following the W3C Activity Streams 2.0 specification where applicable, to ensure consistency, interoperability, and extensibility.

  • Glossary Changes:
    Words like "Activity", "Object" and "Actor" should be added to glossary.

  • User Follow System:
    If a follow/unfollow feature is added, these actions should also be represented as standardized activities (Follow / Unfollow) to maintain consistency across the activity stream. This allows integration with activity feeds, notifications, and analytics without additional data-model redesign.

  • Custom Domain-Specific Activities:
    Certain app-specific actions, such as LogWaste, RedeemReward, or AchieveBadge, can be modeled as custom activity types while remaining compatible with Activity Streams 2.0.

4. Internationalization (i18n) Standards – RELEVANT

Internationalization (i18n) ensures that the platform can be easily adapted for users across different languages, regions, and cultures without requiring engineering changes.
The system must comply with standard internationalization best practices defined by W3C and BCP 47.

🔹 Standard References

⚙️ Possible Functional Requirements

Language and Locale Support

  • The system shall use BCP 47 language tags (e.g., "en-US", "tr-TR", "ar-SA") to identify supported locales across all user-facing and backend services.
  • The system shall support multiple languages, allowing all user interface elements (UI labels, navigation menus, tooltips, and messages) to be translated.
  • Registered and non-registered users shall be able to select their preferred language from the supported locales.
    (Applicable to: User, Registered User, Non-registered User)
  • The platform shall provide a default language fallback (e.g., English) if a translation is missing for a specific string.

Text Direction and Script Handling

  • The platform shall support both Left-to-Right (LTR) and Right-to-Left (RTL) scripts (e.g., Arabic, Hebrew) by applying appropriate text direction and layout adjustments.
  • All UI components, including forms, buttons, and modals, shall adjust automatically based on the selected text direction.

Locale-Aware Formatting

  • The system shall display dates, times, numbers, and currencies in a locale-appropriate format based on the selected language setting.
  • The system shall store all timestamps in UTC and convert them to the user’s local timezone during display.
  • All numeric inputs (e.g., waste amounts, points) shall accept localized number formats (e.g., 1,000.5 vs 1.000,5).
  • Currency values displayed in eco-friendly rewards and points redemption shall reflect locale-specific currency symbols and decimal separators.

Content Internationalization

  • The platform shall ensure all dynamic content (e.g., posts, challenges, achievements) can be localized or tagged with their language metadata.
  • Posts and forums shall display language tags or allow filtering by language to improve discoverability for multilingual users.
    (Applicable to: Post, Forum)
  • System-generated notifications, tooltips, and error messages shall be translated and contextually accurate for each supported language.

Accessibility and Compatibility

  • The system shall maintain accessibility compliance (WCAG 2.1 AA) across all supported languages, including screen reader compatibility for translated content.

  • Text resizing up to 200% shall remain functional and readable for all localized content.

🧩 Example Use Cases

User Action Description i18n Consideration
Viewing profile Registered user views their waste reduction stats Display numbers and dates per locale
Redeeming reward User redeems eco-friendly voucher Currency symbol localized
Joining challenge User joins a community challenge Challenge name and description localized
Browsing forum Non-registered user reads posts Posts filtered or tagged by language

🌍 Benefits

  • Accessibility for global users
  • Compliance with W3C and BCP 47
  • Future readiness for adding new languages
  • Enhanced user experience with culturally appropriate formats