What is the W3C?

The World Wide Web Consortium (W3C), founded in 1994 by World Wide Web (WWW) inventor Tim Berners-Lee, set out the list of international standards for web technologies. These standards help to maintain a consistent level of technical quality and compatibility over an extremely diverse platform and have the added benefit of simplifying the job of the web developer—ensuring they have a finite list of skills they need to learn.

What are the W3C standards?

The W3C standards describe the best practices of web development. These range from recommended programming languages such as HTML and CSS, to the generally accepted principles of web architecture and services.

Technologies that are listed as standards are, as far as the W3C is concerned, the most appropriate solutions currently available for mass use.

The W3C standards are not formally enforced, there is no legal penalty for ignoring their advice. In fact, there are instances when deviations from the standards are acceptable or even necessary in pursuit of a specific use case. However, generally speaking it is good practice to follow the guidelines.

Why are the W3C standards important?

The standards set out but the W3C are invaluable because they ensure a fair and accessible web. Regardless of who you are, or where you are, if you create a web application using the standards, you know that it will work with all others that are W3C compliant, and you know that everyone can access it. Furthermore, they act as quality filters for both the developers and end-users. Developers can have confidence in the tools they are using, knowing they have been vetted by experts. Similarly, users will interact with applications built only with the best tools, so are more likely to have a positive and consistent experience.

Web Content Accessibility Guidelines (WCAG) 2.2

Web Content Accessibility Guidelines (WCAG) 2.2 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.

At the top are four principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust.

1. Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

• This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)

2. Operable - User interface components and navigation must be operable.

• This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)

3. Understandable - Information and the operation of user interface must be understandable.

• This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)

4. Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

• This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)

How to Follow Web Content Accessibility Guidelines

• Provide alternatives for non-text content.
• Provide different options for viewing media content.
• Create content that can be viewed on different platforms.
• Make content easy to hear and see.
• Make all functions keyboard accessible.
• Allow users to adjust timing.
• Avoid content that blinks or flashes a lot.
• Provide tools to help navigate your website.
• Accommodate various input options.
• Ensure text content is grammatically correct.
• Design predictable website features.
• Offer assistance when users make mistakes.
• Write code that works.

Activity Streams 2.0

This specification details a model for representing potential and completed activities using the JSON format. It is intended to be used with vocabularies that detail the structure of activities, and define specific types of activities.

In the most basic sense, an "Activity" is a semantic description of an action. It is the goal of this specification to provide a JSON-based syntax that is sufficient to express metadata about activities in a rich, human-friendly but machine-processable and extensible manner. This can include constructing natural-language descriptions or visual representations about the activity, associating actionable information with various types of objects, communicating or recording activity logs, or delegation of potential actions to other applications.

Key Concepts and Terminology

Expand on some key terms that are fundamental to Activity Streams 2.0, such as:

• Activity: A statement about an action performed by an actor.
• Actor: The entity that performs the activity (e.g., a user, a system).
• Object: The entity on which the activity is performed.
• Verb (Type): Describes the action taken (e.g., "Create", "Update").
• Target: Optional; the destination or result of an activity.

Example of Minimal Activity

In this section, we illustrate how a minimal activity can be represented using the JSON serialization format defined by the Activity Streams 2.0 specification. This example describes the action where a user named Martin creates an image resource.

Example 1: Basic Activity Model

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Martin created an image",
  "type": "Create",
  "actor": "http://www.test.example/martin",
  "object": "http://example.org/foo.jpg"
} 

Explanation:

• The @context provides the necessary schema information for the Activity Streams vocabulary.
• The summary describes the action: Martin created an image.
• The type specifies the activity type, in this case, "Create" represents the creation of an object.
• The actor is the individual who performed the action, represented by a URL.
• The object is the resource created, which in this case is an image, also represented by a URL. This example illustrates how simple activities can be captured and conveyed using the Activity Streams 2.0 model, ensuring compatibility and easy integration across platforms.

Use Cases

Activity Streams 2.0 is commonly applied in various practical scenarios, including:

• Social Networks: Tracking user interactions such as posts, likes, shares, and comments.
• Collaboration Tools: Activity tracking in platforms like GitHub, which logs user activities and contributions.
• Notification Systems: Capturing events like read, dismissed, and acted-upon notifications.

Web Annotation Data Model

Annotations are typically used to convey information about a resource or associations between resources. Simple examples include a comment or tag on a single web page or image, or a blog post about a news article.

The Web Annotation Data Model specification describes a structured model and format to enable annotations to be shared and reused across different hardware and software platforms. Common use cases can be modeled in a manner that is simple and convenient, while at the same time enabling more complex requirements, including linking arbitrary content to a particular data point or to segments of timed multimedia resources.

The specification provides a specific JSON format for ease of creation and consumption of annotations based on the conceptual model that accommodates these use cases, and the vocabulary of terms that represents it.

What’s an Annotation?

An annotation is considered to be a set of connected resources, typically including a body and target, and conveys that the body is related to the target. The exact nature of this relationship changes according to the intention of the annotation, but most frequently conveys that the body is somehow "about" the target.

Key Concepts and Terminology

This section defines specific terms related to the Web Annotation Data Model:

• Annotation: A resource that represents information about another resource.
• Body: The content that provides the annotation's main information.
• Target: The resource that the annotation is addressing.
• Motivation: A resource that describes the purpose of the annotation (e.g., "commenting," "tagging").

Web Annotation Principles

The Web Annotation Data Model is defined using the following basic principles:

• An Annotation is a rooted, directed graph that represents a relationship between resources.
• There are two primary types of resource that participate in this relationship, Bodies and Targets.
• Annotations have 0 or more Bodies.
• Annotations have 1 or more Targets.
• The content of the Body resources is related to, and typically "about", the content of the Target resources.
• Annotations, Bodies and Targets may have their own properties and relationships, typically including creation and descriptive information.
• The intent behind the creation of an Annotation or the inclusion of a particular Body or Target is an important property and represented by a Motivation resource.

Example Use Case

Alice has written a post that makes a comment about a particular web page. Her client creates an Annotation with the post as the body resource, and the web page as the target resource.

Model

Term	Type	Description
@context	Property	The context that determines the meaning of the JSON as an Annotation. The Annotation MUST have 1 or more @context values, and http://www.w3.org/ns/anno.jsonld MUST be one of them. If there is only one value, then it MUST be provided as a string.
id	Property	The identity of the Annotation. An Annotation MUST have exactly 1 IRI that identifies it.
type	Relationship	The type of the Annotation. An Annotation MUST have 1 or more types, and the Annotation class MUST be one of them.
Annotation	Class	The class for Web Annotations. The Annotation class MUST be associated with an Annotation using type.
body	Relationship	The relationship between an Annotation and its Body. There SHOULD be 1 or more body relationships associated with an Annotation but there MAY be 0.
target	Relationship	The relationship between an Annotation and its Target. There MUST be 1 or more target relationships associated with an Annotation.

Example

Example 1: Basic Annotation Model

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "id": "http://example.org/anno1",
  "type": "Annotation",
  "body": "http://example.org/post1",
  "target": "http://example.com/page1"
}