# data[].attributes.body
Students will be able to develop a comprehensive draft plan for creating three Week 5 instructional materials: AI Translation Tools video, AI Errors case study, and AI Ethics infographic within a 20-minute Pomodoro session.

# data[].attributes.body
Students will demonstrate effective team collaboration skills, understand accessibility compliance (WCAG/UDL), and apply design principles for inclusive educational materials.

# data[].attributes.body
Students will utilize Zoom for collaborative planning, Google Docs for shared documentation, and understand the technical requirements for creating accessible digital content.

# data[].attributes.body
How can we efficiently plan and create accessible, inclusive instructional materials that effectively teach AI translation tools while meeting diverse learning needs?

# data[].attributes.body
Teacher demonstrates the three-material framework: 1) Video component (5-7 min AI tools overview), 2) Case Study (1-2 page AI errors analysis), 3) Infographic (AI ethics summary). Emphasize accessibility standards and global perspectives.

# data[].attributes.attachment_link.title
Top 5 machine (AI) translation software you should try | Accuracy comparison & use cases

# data[].attributes.body
Form teams of 3-4 students. Assign specific roles: Facilitator (leads discussion), Note-taker (documents decisions), Designer (visual elements), Accessibility Checker (WCAG/UDL compliance). Use breakout rooms for initial team setup.

# data[].attributes.attachment_link.readable_text
Effective Project Collaboration Tips for Teams

You've analyzed the various methodologies, chosen the frameworks most suited to your project, your team, and your objectives, and found a project management tool that fits your needs. Throughout the entire project life cycle, you'll have to work with your individual team members to function as a cohesive unit.

Just because you've selected the right people with the right skills to accomplish the work, doesn't mean they will collaborate the way you want them to. Different work habits, communication styles, and short-term and long-term goals can throw your entire team (and the project) off track.

Clarifying the behaviors you want your team to practice, and establishing the values you want them to stand for from the beginning starts everyone on the right foot.

We've assembled several best practices for setting up and managing your project team to encourage collaboration for optimal performance.

The Importance of Collaboration in Project Management

Before we get into building a collaborative team environment, let's discuss why collaboration is important. Without collaboration, your company will stagnate. It takes a team's combined ideas and work to pull off a complex project, to innovate, and to come up with the product that beats the competition.

Collaboration is important for two main reasons:

Internal team collaboration increases productivity

When internal teams use tools and work processes that make communication and collaboration more efficient, goals can be met faster and better quality work can be produced. Internal productivity increases with smoother collaboration.

Some proof: A study by McKinsey & Company shows that implementing collaborative processes and networking tools improved productivity by 20-30% in global software development teams.

And California chipmaker Xilinx reported a 25% increase in engineer productivity by using tools that encouraged peer-to-peer collaboration.

Collaborating with external stakeholders increases innovation

When you seek feedback from your customers, partners, and vendors - aka your external stakeholders - and are able to use their feedback to improve your product or service, the customer's actual wants and needs will better align with your product's features.

Today, companies who try to do everything in-house are limited - It's impossible to be good at everything all the time. They need outside ideas and feedback to grow. The same works for your project team. When teams work together, they can achieve amazing things.

How to Set Up a Project Team

So, now that we're on the same page about the value of collaboration, let's take a step back and discuss what makes a project team and how you build one. Merely assigning people tasks is not the same as building a project team.

A project team is a group of people who are all working towards a common goal by bringing valuable and unique skills to the table. Identifying your project team members, defining your team's identity, and standardizing its operating practices are all critical to a successful project.

So what should you consider when assembling your project team?

Project Needs. Understand the scope of the project first allows you to strategically choose who needs to be on the team.

Skill set. Choosing team members who can offer a diverse set of unique and relevant skills is crucial. If your team lacks a certain skill set, a task may not be completed correctly. oo many people with the same skills can cause confusion over ownership.

Capacity. Even if you find the perfect person for a part of your project, if they're overloaded with work, they can become a roadblock. Find team members who have availability in their upcoming project schedules.

Work styles. Different people have different work styles and personalities. It's important to understand how these differences may affect your team dynamic and embrace them once the project has started.

What Makes a Successful Project Team

Your project team can vary depending on project scope and skills needed, but the elements of a successful project team are more or less consistent across the board.

Strong team leadership. Every team needs a leader who can bring out the best in their teammates. Understanding each of your team members' individual strengths and how to bring them out is vital to the success of the team as a whole.

Clear goals and purpose. When the roadmap and goals are clear, it's much easier for a team to see where they're going and how their contribution will matter down the road. Encourage them to rally around your cause with a clear vision.

Standardized operating procedures. When conflicts arise or a task needs to be assigned, teams need to know how to take action. Creating standard processes and workflows, along with clear roles eliminates confusion and empowers your team to blow past roadblocks.

Diversity. Time and time again studies have shown that diversity improves performance. A strong project team will include a variety of skill sets, as well as a diversity of race, gender, and cultural backgrounds.

Bonding time. Finding time for project team members to get to know each other and build a rapport helps build trust, breaks down barriers, and opens communication lanes. Finding time for team-building exercises and to celebrate victories, no matter how big or small, can go a long way. Getting everyone in the room at the start of the project for a kickoff helps everyone stay on the same page from the beginning.

Make the Project Kickoff Meeting Successful

Before project work formally begins, hold a project kickoff meeting to get everyone on the same page. This is a crucial first step that sets the tone for the work that follows. It's typically the one chance to share the project's objectives and overall plan with every stakeholder.

Successful kickoff meetings require preparation. Here are 8 steps to making your kickoff meeting a success:

1. Establish vision and deliverables: Set a common goal for everyone. Lay out what needs to get done and by when.

2. Identify team and set roles: Who does what? Create a list detailing who's responsible for what and include contact info for easy communication.

3. Develop initial project plan: Present your initial project plan, but understand that details may shift during discussions with your team at the kickoff. Know how you want to approach the project, but be flexible.

4. Define metrics for success: How will the project be measured? What will make it successful? Set expectations and goals early.

5. Identify potential risks and bottlenecks: Prepare the team for potential roadblocks and have a process in place to handle them quickly should they arise.

6. Establish logistics for team communication: What is the preferred method of communication? What is the best way to provide status updates? Establish a consistent process (daily, weekly meetings) and determine the technology for it.

7. Choose work process or project management methodology: Establish which methodologies and frameworks the team will follow to align work styles and expectations.

8. Decide which tools you'll use: Ensure everyone has the tools they need to accomplish their tasks.

Tips for Effective Team Management

Now that the project is underway, it's your job to keep everyone motivated, on track, and working together. Motivational speaker Brian Tracy said it best: Successful people are simply those with successful habits. Your team's productivity habits are the magic ingredients to your project's success. If you have the right team habits in place, your team will complete the project on time and collaborate without much friction.

Even if your team doesn't have the right work habits now, you can help them build new, more productive behaviors. Just remember that it takes anywhere from 66 days to 8 months to cement a new habit. And proceed with sensitivity - after all, we humans are quite resistant to change.

Here are 5 ways you can help your team build new habits:

Lead by example. Define the habit you want the team to practice, then do it yourself. Be the role model. Your team will follow your lead when they see the benefits of this new habit on your daily work.

Find your early adopters. Get assistance from your team evangelists - the enthusiastic team members who can quickly adopt new tools or new behaviors and can help but spread it to the rest of the team.

Use small wins to gain big victories. Small wins can motivate the team to keep going the rest of the way, even though it may seem difficult at first. Celebrate progress no matter how small, and encourage team members to keep up the good work.

Motivate your team. Intellectual reasoning won't always work without some emotional heft behind it. Give your team incentives to practice this new habit. Make it fun.Turn it into a game. Be creative.

Blend new habits with old. It's always easier to transition to new habits when you piggyback on older, existing behaviors. It makes the new habit feel more familiar and ensures a more natural transition. Identify behavior your team is already doing well, and help them take it to the next level.

Learn more about these 5 tactics to increase team effectiveness in our free ebook: 5 Strategies for Forming Team Productivity Habits.

Next Steps
Proceed with sensitivity

Just a word of caution - when people are faced with change, the reaction pattern mimics that of grief. Your team will spiral from denial to anger, confusion, depression, and crisis, before finally settling into acceptance, and new confidence. So if you're going to build new team habits, the new behavior will take time to build roots and their reactions will be varied. Proceed with requisite amounts of sensitivity, while still motivating the team to forge better, more productive, behavioral patterns. For more on this topic, read our free ebook: Accelerating Change Management: Getting 7 Personalities On Board.

How to Create a Collaborative Work Environment

A collaborative work environment isn't just about having collaborative tools, processes, and workflows in place. It's also about striving for common goals despite differences in work styles, personal goals, or cultural backgrounds. A collaborative work environment should be a safe space where everyone feels supported and able to voice their opinions.

As organizations grow and become increasingly dispersed, more workers are collaborating from across great distances. As a result, cultural intelligence - the ability to embrace different mindsets in challenging situations - is becoming more and more important.

In order to lead a multi-cultural (and increasingly multi-regional) team to success, you must be able to bridge cultural differences with sensitivity and sincerity. Here are some best practices:

Learn about one another. Find time to talk about things that are not work or project-related. Ask your teammates about their customs, holidays, weather, entertainment, and so on. Just show an interest - and remember what they share with you!

Embrace different learning and communication styles. Some cultures can be more direct, while others prefer to stay in the background until asked for their opinion. Get to know each team member's preferences, so you can engage with them as effectively as possible.

Always recap the main points of the meeting. And always make responsibilities and next steps crystal clear for each team member. In addition to providing clarity to action items, this also ensures team members feel included and invested.

Get everyone involved. Different people have different communication styles. Just because someone doesn't speak up doesn't mean they don't have good ideas. Find ways to get feedback from everyone, even those who may appear more introverted.

Incorporate humor (where appropriate). We don't mean you should joke about everything all the time, but lightening the mood always can help people open up and improve work relationships. Make sure to read your team on this one. Not everyone responds to humor in the same way.

Your next action
Ask questions

The common themes for working with different cultures is: respect and knowledge. Respect the different cultures and backgrounds on your team. If you don't know something, ask a question in order to better understand where your team member is coming from.

Project Management Collaboration Tips and Techniques

It can be easy to lose sight of collaboration best practices with deadlines looming overhead, but implementing them throughout the entire project will help optimize team performance.

Make meetings more efficient

While meetings can be a valuable time for collaboration, unnecessarily long meetings can be a collaboration killer. When scheduling a meeting, remember these tips:

Lose status update meetings and use a software tool instead.

Only invite people who are absolutely necessary. Don't waste other people's time.

Create a goal-oriented agenda and stick to it.

End your meeting by clarifying everyone's next steps.

Try a more effective brainstorming technique

Brainstorming meetings can help spark collaborative thinking and great new ideas. But when brainstorming goes wrong, it can actually discourage team members from contributing - or even worse, make them feel like their opinions aren't valued.

When embarking on a brainstorming session, try one of these techniques to make it more effective and empowering:

Brain writing: The team leader shares the topic with the team, and the team members individually write down their ideas. This creates a safe space for everyone to come up with ideas individually before any discussion begin.

Figuring storming: Think about how a person such as your boss, a famous celebrity, or a successful CEO might handle the situation. It's like role playing, but with a creative problem in mind.

Brain-netting: Create a communal folder in your project management platform where your team members (especially remote workers) can jot down ideas and share them with the entire team.

Rapid ideation: Clarify the ideas and solutions you want your team to brainstorm. Set time limit and have your team come up with as many ideas as possible using whiteboards, post-its, or plain pen and paper.

Round robin brainstorming: Gather in a circle and have each person offer an idea in turn, while a facilitator records each idea. Discussion starts only after everyone's had a chance to share.

Starbursting: Challenge the team to come up with as many questions as they can about your topic. Start with the 5 Ws: who, what, where, when, and why.

Stepladder Technique: Once the topic is shared, everyone leaves the room except two members of the team. These two discuss the topic and their ideas. Then, one new member is added and will contribute his/her idea before the original two share theirs. Repeat the process until everyone from the original group is back in the room.

Further Reading:
Resolve conflict quickly

Conflicts are inevitable when collaborating on group projects. They're emotional, sometimes dramatic, and often exhausting. But when conflicts get resolved, they lead to stronger relationships within the team, a better understanding how to collaboration and opportunities for growth.

Some pointers for resolving conflict quickly:

Keep calm. It's not always easy to keep your emotions out of a conflict, but approaching a conflict rationally will help in the long run.

Pay attention to both verbal and nonverbal communication. What you say matters just as much as what you don't say. They say more than half of perceived communication is done nonverbally through body language.

Keep your language and your tone neutral. The intonation of your voice can be just as important as the words you're speaking. Remaining neutral can help you get your point across without ruffling more feathers.

Avoid threats and accusations. Accusations and threats typically take situations in the opposite direction you want to head. Rather than escalating the conflict, take a breath and listen to what the other person has to say. Understanding their side of the story will help you see things from their perspective.

Be generous. Keep in mind that resolving the conflict is more important for the working relationship - and your team's ultimate success - than "winning" the fight. Persuade those in the conflict to let go of grudges and forgive and forget.

How to improve collaboration in the workplace

While effective collaboration will ultimately stem from the willingness of your project team, there are several tips and techniques you can use to encourage them:

Build a collaborative work environment. Organize an open work area away from personal workspaces where team members can meet and work together for the duration of the project.

Encourage effective remote collaboration. Have an always-on video conference system in place so that remote team members can be reached any time while they work.

Use tools for sharing. Effective collaboration requires the right tools and technology. At the bare minimum you will need a real-time chat tool, a project management/task management tool, a knowledge base tool, and a file sharing tool. Better yet if you have one tool that can do all of the above.

Encourage engagement everywhere. Line the hallway and meeting rooms with whiteboards and encourage team members to draft plans and brainstorm ideas on them. Reward those who contribute.
Further Reading:
Tips for Remote Collaboration and Virtual Meetings

Remote collaboration is becoming more and more common, if not the norm. Modern workers and workplaces need to adapt to accommodate remote workers and encourage collaboration no matter where they are or what time zone they're in.

Tips for using a collaboration software tool

When project managing a distributed team in a variety of locations, a collaboration software (or project management tool) is an effective way to keep everyone on the same page and all of your project information in one place. However, having a tool doesn't magically make collaboration happen. Here are 10 best practices when using a collaboration software tool:

Share proactively. Assign team members to tasks they need to be aware of and @mention them in the comments so they receive alerts when the ball is in their court.

Put every project into your collaboration tool/project management tool. Use your tool as a single source of all project-related materials and notes so they're easy to find for everyone, no matter when they joined the project.

Create water cooler channels. Creating channels in your communication tools where team members can discuss non-work related topics allows them to get to know each other and be social even from afar.

Celebrate small wins. Collaboration tools are a great place to announce and share victories no matter how big or small. Even a short message can go a long way.

Balance the load. You can't collaborate well if you're overloaded with work. Use the collaboration tool's visibility and resource management features to ensure project tasks are balanced among your team members.

Further Reading:
Tips for Better Virtual Meeting Communication

Communicating with team members is always a bit more challenging when you're not face-to-face, but new technologies are helping to make virtual meetings easier. Keep in mind these virtual meeting best practices:

Be clear who you're speaking to. Avoid repeating yourself by saying a person's name before asking something.

Always introduce yourself. Never assume everyone knows what you sound like or look like. Always tell people who you are and hopefully others follow suit.

Have a backup technology to count on. The last thing you want to do is scramble for another conference call line or make everyone download a new video software. Have a contingency to fall back on in case your first choice isn't working.

Set proper etiquette in place. Guidelines for your calls or video meetings will make virtual meetings more efficient. Ask people to mute themselves when not speaking.

Without a doubt, collaboration is important - not just for the success of your projects, but for the continued growth of your organization. It's an essential ingredient for day-to-day project work, but more importantly, it's the X factor that defines your organization's culture and attracts the top performers to your company.
Next Steps

Read our ebook about achieving operational excellence based on insights from 15,000 of the world's leading companies.

# data[].attributes.attachment_link.title
Tips for Confident Project Management Collaboration | Project Management Guide

# data[].attributes.attachment_link.description
You've analyzed the various methodologies, chosen the frameworks most suited to your project, your team, and your objectives, and found a project management tool that fits your needs. Throughout the entire project life cycle, you'll have to work with your individual team members to function as a cohesive unit.

# data[].attributes.body
Teams conduct planning meetings using Zoom screen sharing. Practice using shared Google Docs for collaborative drafting. Teacher circulates through breakout rooms providing guidance and support. Students could use Padlet to share initial ideas and gather feedback from other teams.

# data[].attributes.attachment_link.title
STOP Wasting Time on Google Docs, Try Zoom Docs Instead!

# data[].attributes.body
Provide detailed template covering: Video specifications (high-contrast slides, 16pt+ font, global examples, captions), Case Study requirements (CC-licensed OER, tagged PDF, alt-text), Infographic criteria (Canva CC BY-SA, high-contrast, keyboard navigation).

# data[].attributes.attachment_link.readable_text
Instructional designers are responsible for creating inclusive and accessible courses following the universal design principles to guarantee access for all of our leaners. Any course learning materials posted in the course including Word, PPT, PDF, Excel and LMS reading pages MUST adhere to basic accessibility principles. You can download accessible Word, PDF, and Excel training documents from the T&L accessibility training blog.

Incorporating the ten most basic accessibility principles, below is a checklist you can use to design accessible online courses meeting the accessibility standards.

Provide a good heading structure.

Ensure all readings (PDF) are downloadable and are not scanned images.

Provide appropriate alternative text or text description for images.

Check the quiz and exam for any missing text description.

Exception: decorative images or images in the linked or external resources

Use accessibility format-checked templates like the T&L PPT template for live sessions.

Create lists using the bullet or number list tools.

Add a meaningful and unique text for links.
Exception: simple representative URL with specified purposes

Add column and/or row header cells in tables and a table caption for complex tables.
Exception: role="presentation" for a layout purpose

Choose highly readable fonts, i.e., san serif fonts like Arial, Calibri, & Helvetica.

Avoid using color as the only means to deliver information. For emphasis, use font styles (bold and italic) together with color.

Ensure a strong color contrast between text and background color.

Provide accurate captions and transcripts for video and audio files.

Ensure all the videos have closed captions turned on in the player.

Do not set auto-play for videos or audio files.

Test with a screen-reader and a keyboard only.

Keyboard navigation short keys

If you have any questions or suggestions on this topic, please contact Jinhee Choo (teaching@business.illinois.edu).

# data[].attributes.attachment_link.description
Instructional designers are responsible for creating inclusive and accessible courses following the universal design principles to guarantee access for all of our leaners. Any course learning materials posted in the course including Word, PPT, PDF, Excel and LMS reading pages MUST adhere to basic accessibility principles.

# data[].attributes.body
Teams work independently to create their draft plans using the 20-minute Pomodoro technique. Focus on detailed specifications for each material while ensuring accessibility compliance.

# data[].attributes.attachment_link.description
A simple Pomodoro Timer app that works on a desktop & mobile browser. Pomofucus will help you manage your time and let you focus on any tasks such as study, writing, or coding.

# data[].attributes.body
For advanced learners: Research additional WCAG 2.1 AA standards and CAST UDL guidelines. For struggling learners: Provide simplified accessibility checklist and template examples.

# data[].attributes.attachment_link.readable_text
The UDL Guidelines are a tool used in the implementation of Universal Design for Learning, a framework to improve and optimize teaching and learning for all people based on scientific insights into how humans learn. Learn more about the Universal Design for Learning framework from CAST. The UDL Guidelines can be used by educators, curriculum developers, researchers, parents, and anyone else who wants to implement the UDL framework in a learning environment. These guidelines offer a set of concrete suggestions that can be applied to any discipline or domain to ensure that all learners can access and participate in meaningful, challenging learning opportunities.

Reenvisioning the UDL Guidelines

Because the UDL Guidelines are meant to be informed by feedback from the field as well as new research, they have been updated several times in the past. We are in the process of updating the Guidelines once again in our UDL Rising to Equity initiative.

This update will focus specifically on addressing systemic barriers that result in inequitable learning opportunities and outcomes. CAST aims to develop a transparent, inclusive, and community-driven process. If you are interested in collaborating and staying updated on our progress, we invite you to complete a brief survey.

# data[].attributes.attachment_link.description
The UDL Guidelines are a tool used in the implementation of Universal Design for Learning, a framework to improve and optimize teaching and learning for all people based on scientific insights into how humans learn. Learn more about the Universal Design for Learning framework from CAST. The UDL Guidelines can be used by educators, curriculum developers, researchers, parents, and anyone else who wants to implement the UDL framework in a learning environment. These guidelines offer a set of concrete suggestions that can be applied to any discipline or domain to ensure that all learners can access and participate in meaningful, challenging learning opportunities.

# data[].attributes.body
Challenge teams to research and include specific examples from African markets, Japanese translation contexts, or other global AI translation scenarios in their materials planning.

# data[].attributes.attachment_link.title
AI Translation’s Blind Spot: Why Human Translators Are Vital for Capturing Cultural Context in 2024 – Translata.eu

# data[].attributes.attachment_link.description
Discover why AI translation falls short in cultural nuance and context in 2024. Learn how human translators remain essential for accurate, culturally-sensitive translations in our increasingly global world.

# data[].attributes.headline
Formative Assessment: Planning Progress Check

# data[].attributes.subject
Formative Assessment: Planning Progress Check

# data[].attributes.body
Monitor team progress through Zoom breakout room visits. Observe collaboration effectiveness, role implementation, and adherence to accessibility guidelines. Provide real-time feedback.

# data[].attributes.body
Teams could use Padlet to post their draft plans for peer review and constructive feedback. Focus on completeness, accessibility considerations, and feasibility within given constraints.

# data[].attributes.headline
Summative Assessment: Draft Plan Quality

# data[].attributes.subject
Summative Assessment: Draft Plan Quality

# data[].attributes.body
Evaluate final draft plans using rubric covering: completeness of three materials, accessibility compliance, team collaboration evidence, and adherence to time constraints. Include self-assessment component.

# data[].attributes.body
Specific assessment of WCAG/UDL integration in planning documents. Teams must demonstrate understanding of inclusive design principles and practical implementation strategies.

# data[].attributes.attachment_link.readable_text
Abstract

Web Content Accessibility Guidelines (WCAG) 2.1 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.

WCAG 2.1 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and educational material.

WCAG 2.1 extends Web Content Accessibility Guidelines 2.0 [], which was published as a W3C Recommendation December 2008. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0. The WG intends that for policies requiring conformance to WCAG 2.0, WCAG 2.1 can provide an alternate means of conformance. The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0. While WCAG 2.0 remains a W3C Recommendation, the W3C advises the use of WCAG 2.1 to maximize future applicability of accessibility efforts. The W3C also encourages use of the most current version of WCAG when developing or updating Web accessibility policies.

Status of This Document
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in theW3C technical reports index at https://www.w3.org/TR/.
This is a Recommendation of WCAG 2.1 by the Accessibility Guidelines Working Group. This incorporates errata and are described in the change log. At some point additional changes might be incorporated into an Edited or Amended Recommendation.

To comment, file an issue in the W3C WCAG GitHub repository. Although the proposed Success Criteria in this document reference issues tracking discussion, the Working Group requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org ( comment archive).

This document was published by the Accessibility Guidelines Working Group as a Recommendation using the Recommendation track.

W3C recommends the wide deployment of this specification as a standard for the Web.

A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by W3C and its Members, and has commitments from Working Group members to royalty-free licensing for implementations.

This document was produced by a group operating under the 1 August 2017 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 12 June 2023 W3C Process Document.

This section is non-normative.

Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.

WCAG 2.1 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.1 builds on WCAG 2.0 [], which in turn built on WCAG 1.0 [WAI-WEBCONTENT] and is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. For an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.

Significant challenges were encountered in defining additional criteria to address cognitive, language, and learning disabilities, including a short timeline for development as well as challenges in reaching consensus on testability, implementability, and international considerations of proposals. Work will carry on in this area in future versions of WCAG. We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive disabilities, people with low-vision, and more.

Web accessibility depends not only on accessible content but also on accessible Web browsers and other user agents. Authoring tools also have an important role in Web accessibility. For an overview of how these components of Web development and interaction work together, see:

Where this document refers to WCAG 2 it is intended to mean any and all versions of WCAG that start with 2.

The individuals and organizations that use WCAG vary widely and include Web designers and developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying needs of this audience, several layers of guidance are provided including overall principles, general guidelines, testable success criteria and a rich collection of sufficient techniques, advisory techniques, and documented common failures with examples, resource links and code.

Principles - At the top are four principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust. See also Understanding the Four Principles of Accessibility.

Guidelines - Under the principles are guidelines. The 13 guidelines provide the basic goals that authors should work toward in order to make content more accessible to users with different disabilities. The guidelines are not testable, but provide the framework and overall objectives to help authors understand the success criteria and better implement the techniques.

Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.1 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest). Additional information on WCAG levels can be found in Understanding Levels of Conformance.

Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG 2.1 document itself, the working group has also documented a wide variety of techniques. The techniques are informative and fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory. The advisory techniques go beyond what is required by the individual success criteria and allow authors to better address the guidelines. Some advisory techniques address accessibility barriers that are not covered by the testable success criteria. Where common failures are known, these are also documented. See also Sufficient and Advisory Techniques in Understanding WCAG 2.1.

All of these layers of guidance (principles, guidelines, success criteria, and sufficient and advisory techniques) work together to provide guidance on how to make content more accessible. Authors are encouraged to view and apply all layers that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users.

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.

The WCAG 2.1 document is designed to meet the needs of those who need a stable, referenceable technical standard. Other documents, called supporting documents, are based on the WCAG 2.1 document and address other important purposes, including the ability to be updated to describe how WCAG would be applied with new technologies. Supporting documents include:

1. How to Meet WCAG 2.1 - A customizable quick reference to WCAG 2.1 that includes all of the guidelines, success criteria, and techniques for authors to use as they are developing and evaluating Web content. This includes content from WCAG 2.0 and WCAG 2.1 and can be filtered in many ways to help authors focus on relevant content.

2. Understanding WCAG 2.1 - A guide to understanding and implementing WCAG 2.1. There is a short "Understanding" document for each guideline and success criterion in WCAG 2.1 as well as key topics.

3. Techniques for WCAG 2.1 - A collection of techniques and common failures, each in a separate document that includes a description, examples, code and tests.

4. The WCAG Documents - A diagram and description of how the technical documents are related and linked.

See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.1 supporting material, including education resources related to WCAG 2. Additional resources covering topics such as the business case for Web accessibility, planning implementation to improve the accessibility of Web sites, and accessibility policies are listed in WAI Resources.

WCAG 2.1 meets a set of requirements for WCAG 2.1 which, in turn, inherit requirements from WCAG 2.0. Requirements structure the overall framework of guidelines and ensure backwards compatibility. The Working Group also used a less formal set of acceptance criteria for success criteria, to help ensure success criteria are similar in style and quality to those in WCAG 2.0. These requirements constrained what could be included in WCAG 2.1. This constraint was important to preserve its nature as a dot-release of WCAG 2.

WCAG 2.1 was initiated with the goal to improve accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Many ways to meet these needs were proposed and evaluated, and a set of these were refined by the Working Group. Structural requirements inherited from WCAG 2.0, clarity and impact of proposals, and timeline led to the final set of success criteria included in this version. The Working Group considers that WCAG 2.1 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.

WCAG 2.1 builds on and is backwards compatible with WCAG 2.0, meaning web pages that conform to WCAG 2.1 also conform to WCAG 2.0. Authors that are required by policy to conform with WCAG 2.0 will be able to update content to WCAG 2.1 without losing conformance with WCAG 2.0. Authors following both sets of guidelines should be aware of the following differences:

WCAG 2.1 extends WCAG 2.0 by adding new success criteria, definitions to support them, guidelines to organize the additions, and a couple additions to the conformance section. This additive approach helps to make it clear that sites which conform to WCAG 2.1 also conform to WCAG 2.0, thereby meeting conformance obligations that are specific to WCAG 2.0. The Accessibility Guidelines Working Group recommends that sites adopt WCAG 2.1 as their new conformance target, even if formal obligations mention WCAG 2.0, to provide improved accessibility and to anticipate future policy changes.

The following Success Criteria are new in WCAG 2.1:

The new success criteria may reference new terms that have also been added to the glossary and form part of the normative requirements of the success criteria.

In the Conformance section, a third note about page variants has been added to Full Pages, and an option for machine-readable metadata added to Optional Components of a Conformance Claim.

In order to avoid confusion for implementers for whom backwards compatibility to WCAG 2.0 is important, new success criteria in WCAG 2.1 have been appended to the end of the set of success criteria within their guideline. This avoids the need to change the section number of success criteria from WCAG 2.0, which would be caused by inserting new success criteria between existing success criteria in the guideline, but it means success criteria in each guideline are no longer grouped by conformance level. The order of success criteria within each guideline does not imply information about conformance level; only the conformance level indicator (A / AA / AAA) on the success criterion itself indicates this. The WCAG 2.1 Quick Reference provides ways to view success criteria grouped by conformance level, along with many other filter and sort options.

WCAG 2.1 uses the same conformance model as WCAG 2.0 with a couple additions, which is described in the Conformance section. It is intended that sites that conform to WCAG 2.1 also conform to WCAG 2.0, which means they meet the requirements of any policies that reference WCAG 2.0, while also better meeting the needs of users on the current Web.

In parallel with WCAG 2.1, the Accessibility Guidelines Working Group is developing another major version of accessibility guidelines. The result of this work is expected to be a more substantial restructuring of web accessibility guidance than would be realistic for dot-releases of WCAG 2. The work follows a research-focused, user-centered design methodology to produce the most effective and flexible outcome, including the roles of content authoring, user agent support, and authoring tool support. This is a multi-year effort, so WCAG 2.1 is needed as an interim measure to provide updated web accessibility guidance to reflect changes on the web since the publication of WCAG 2.0. The Working Group might also develop additional interim versions, continuing with WCAG 2.2, on a similar short timeline to provide additional support while the major version is completed.

This section lists requirements for conformance to WCAG 2.1. It also gives information about how to make conformance claims, which are optional. Finally, it describes what it means to be accessibility supported, since only accessibility-supported ways of using technologies can be relied upon for conformance. Understanding Conformance includes further explanation of the accessibility-supported concept.

The main content of WCAG 2.1 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [].

In order for a Web page to conform to WCAG 2.1, all of the following conformance requirements must be satisfied:

One of the following levels of conformance is met in full.

For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided.

For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.

For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.

Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)

An online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) conform in order for any page that is part of the process to conform.

1. when any technology that is not relied upon is turned on in a user agent,

2. when any technology that is not relied upon is turned off in a user agent, and

3. when any technology that is not relied upon is not supported by a user agent

In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:

1.4.2 - Audio Control,

2.1.2 - No Keyboard Trap,

2.3.1 - Three Flashes or Below Threshold, and

2.2.2 - Pause, Stop, Hide.

For more information, including examples, see Understanding Conformance Requirements.

Conformance is defined only for Web pages. However, a conformance claim may be made to cover one page, a series of pages, or multiple related Web pages.

Conformance claims are not required. Authors can conform to WCAG 2.1 without making a claim. However, if a conformance claim is made, then the conformance claim must include the following information:

1. Date of the claim

2. Guidelines title, version and URI "Web Content Accessibility Guidelines 2.1 at https://www.w3.org/TR/WCAG21/"

3. Conformance level satisfied: (Level A, AA or AAA)

4. A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim.

The Web pages may be described by list or by an expression that describes all of the URIs included in the claim.

Web-based products that do not have a URI prior to installation on the customer's Web site may have a statement that the product would conform when installed.

5. A list of the Web content technologies relied upon.

In addition to the required components of a conformance claim above, consider providing additional information to assist users. Recommended additional information includes:

A list of success criteria beyond the level of conformance claimed that have been met. This information should be provided in a form that users can use, preferably machine-readable metadata.

A list of the specific technologies that are " used but not relied upon."

A list of user agents, including assistive technologies that were used to test the content.

A list of specific accessibility characteristics of the content, provided in machine-readable metadata.

Information about any additional steps taken that go beyond the success criteria to enhance accessibility.

A machine-readable metadata version of the list of specific technologies that are relied upon.

A machine-readable metadata version of the conformance claim.

Sometimes, Web pages are created that will later have additional content added to them. For example, an email program, a blog, an article that allows users to add comments, or applications supporting user-contributed content. Another example would be a page, such as a portal or news site, composed of content aggregated from multiple contributors, or sites that automatically insert content from other sources over time, such as when advertisements are inserted dynamically.

In these cases, it is not possible to know at the time of original posting what the uncontrolled content of the pages will be. It is important to note that the uncontrolled content can affect the accessibility of the controlled content as well. Two options are available:

1. A determination of conformance can be made based on best knowledge. If a page of this type is monitored and repaired (non-conforming content is removed or brought into conformance) within two business days, then a determination or claim of conformance can be made since, except for errors in externally contributed content which are corrected or removed when encountered, the page conforms. No conformance claim can be made if it is not possible to monitor or correct non-conforming content;
OR

2. A "statement of partial conformance" may be made that the page does not conform, but could conform if certain parts were removed. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.1 at level X if the following parts from uncontrolled sources were removed." In addition, the following would also be true of uncontrolled content that is described in the statement of partial conformance:

1. It is not content that is under the author's control.

2. It is described in a way that users can identify (e.g., they cannot be described as "all parts that we do not control" unless they are clearly marked as such.)

A "statement of partial conformance due to language" may be made when the page does not conform, but would conform if accessibility support existed for (all of) the language(s) used on the page. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.1 at level X if accessibility support existed for the following language(s):"

abbreviation

shortened form of a word, phrase, or name where the abbreviation has not become part of the language

1. initialisms are shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase

Not defined in all languages.

SNCF is a French initialism that contains the initial letters of the Société Nationale des Chemins de Fer, the French national railroad.

ESP is an initialism for extrasensory perception.

2. acronyms are abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word

NOAA is an acronym made from the initial letters of the National Oceanic and Atmospheric Administration in the United States.

accessibility supported

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents

To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

1. The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,
AND

2. The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:

1. The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);
OR

2. The technology is supported in a widely-distributed plug-in that is also accessibility supported;
OR

3. The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported;
OR

4. The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:

does not cost a person with a disability any more than a person without a disability and

is as easy to find and obtain for a person with a disability as it is for a person without disabilities.

alternative for time-based media

ambiguous to users in general

picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII)

assistive technology (as used in this document)

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents

screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order to improve the visual readability of rendered text and images;

screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;

text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;

speech recognition software, which may be used by people who have some physical disabilities;

alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);

alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

audio description

narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone

a time-based presentation that contains only audio (no video and no interaction)

switch back and forth between two visual states in a way that is meant to draw attention

blocks of text

more than one sentence of text

initialism for "Completely Automated Public Turing test to tell Computers and Humans Apart"

synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content

changes of context

major changes that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously

Changes in context include changes of:

conformance

satisfying all the requirements of a given standard, guideline or specification

conforming alternate version

version that

1. conforms at the designated level, and

2. provides all of the same information and functionality in the same human language, and

3. is as up to date as the non-conforming content, and

4. for which at least one of the following is true:

1. the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or

2. the non-conforming version can only be reached from the conforming version, or

3. the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version

See Understanding Conforming Alternate Versions

content (Web content)

context-sensitive help

contrast ratio

(L1 + 0.05) / (L2 + 0.05), where

correct reading sequence

any sequence where words and paragraphs are presented in an order that does not change the meaning of the content

visual angle of about 0.0213 degrees

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. This unit is density-independent, and distinct from actual hardware pixels present in a display. User agents and operating systems should ensure that a CSS pixel is set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [css3-values], which takes into account the physical dimensions of the display and the assumed viewing distance (factors that cannot be determined by content authors).

platform event that occurs when the trigger stimulus of a pointer is depressed

The down-event may have different names on different platforms, such as "touchstart" or "mousedown".

a sudden, unexpected situation or occurrence that requires immediate action to preserve health, safety, or property

if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

extended audio description

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description

a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range

functionality

processes and outcomes achievable through user action

general flash and red flash thresholds

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:

1. there are no more than three general flashes and / or no more than three red flashes within any one-second period; or

2. the combined area of flashes occurring concurrently occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance

where:

A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance (1.0) where the relative luminance of the darker image is below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and

A red flash is defined as any pair of opposing transitions involving a saturated red

Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical viewing distance) on a side does not violate the thresholds.

The working definition (as of 2022) in the field for "pair of opposing transitions involving a saturated red" is a pair of opposing transitions where, one transition is either to or from a state with a value R/(R + G + B) that is greater than or equal to 0.8, and the difference between states is more than 0.2 (unitless) in the CIE 1976 UCS chromaticity diagram. [ISO_9241-391]

human language

language that is spoken, written or signed (through visual or tactile means) to communicate with humans

phrase whose meaning cannot be deduced from the meaning of the individual words and the specific words cannot be changed without losing the meaning

In Japanese, the phrase "さじを投げる" literally translates into "he throws a spoon," but it means that there is nothing he can do and finally he gives up.

In Dutch, "Hij ging met de kippen op stok" literally translates into "He went to roost with the chickens," but it means that he went to bed early.

image of text

text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect

informative

for information purposes and not required for conformance

input error

information provided by the user that is not accepted

This includes:

1. Information that is required by the Web page but omitted by the user

2. Information that is provided by the user but that falls outside the required data format or values

keyboard interface

interface used by software to obtain keystroke input

A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.

A touchscreen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech-to-text applications with "keyboard emulation" functionality.

keyboard shortcut

alternative means of triggering an action by the pressing of one or more keys

large scale (text)

with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

legal commitments

link purpose

nature of the result obtained by activating a hyperlink

information captured from a real-world event and transmitted to the receiver with no more than a broadcast delay

lower secondary education level

the two or three year period of education that begins after completion of six years of school and ends nine years after the beginning of primary education

This definition is based on the International Standard Classification of Education [].

process or technique for achieving a result

media alternative for text

motion animation

text by which software can identify a component within Web content to the user

navigated in the order defined for advancing focus (from one element to the next) using a keyboard interface

non-text content

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language

required for conformance

on a full-screen window

stopped by user request and not resumed until requested by user

pointer input

input from a device that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact

prerecorded

information that is not live

presentation

rendering of the content in a form to be perceived by users

primary education level

six year time period that begins between the ages of five and seven, possibly without any previous education

This definition is based on the International Standard Classification of Education [].

series of user actions where each action is required in order to complete an activity

programmatically determined (programmatically determinable)

determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

programmatically determined link context

additional information that can be programmatically determined from relationships with a link, combined with the link text, and presented to users in different modalities

programmatically set

set by software using methods that are supported by user agents, including assistive technologies

pure decoration

serving only an aesthetic purpose, providing no information, and having no functionality

real-time event

event that a) occurs at the same time as the viewing and b) is not completely generated by the content

relationships

meaningful associations between distinct pieces of content

relative luminance

the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:

if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

if GsRGB <= 0.04045 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4

if BsRGB <= 0.04045 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

and RsRGB, GsRGB, and BsRGB are defined as:

The "^" character is the exponentiation operator. (Formula taken from [].)

relied upon (technologies that are)

the content would not conform if that technology is turned off or is not supported

same functionality

same relative order

satisfies a success criterion

the success criterion does not evaluate to 'false' when applied to the page

set of web pages

collection of web pages that share a common purpose and that are created by the same author, group or organization

Examples include:

a publication which is split across multiple Web pages, where each page contains one chapter or other significant section of the work. The publication is logically a single contiguous unit, and contains navigation features that enable access to the full set of pages.

an e-commerce website shows products in a set of Web pages that all share the same navigation and identification. However, when progressing to the checkout process, the template changes; the navigation and other elements are removed, so the pages in that process are functionally and visually different. The checkout pages are not part of the set of product pages.

a blog on a sub-domain (e.g. blog.example.com) which has a different navigation and is authored by a distinct set of people from the pages on the primary domain (example.com).

sign language

a language using combinations of movements of the hands and arms, facial expressions, or body positions to convey meaning

sign language interpretation

translation of one language, generally a spoken language, into a sign language

single pointer

pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures

specific sensory experience

dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes

States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse.

status message

change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

1. The way the parts of a Web page are organized in relation to each other; and

2. The way a collection of Web pages is organized

style property

property whose value determines the presentation (e.g. font, color, size, location, padding, volume, synthesized speech prosody) of content elements as they are rendered (e.g. onscreen, via loudspeaker, via braille display) by user agents

Style properties can have several origins:

User agent default styles: The default style property values applied in the absence of any author or user styles. Some web content technologies specify a default rendering, others do not;

Author styles: Style property values that are set by the author as part of the content (e.g. in-line styles, author style sheets);

User styles: Style property values that are set by the user (e.g. via user agent interface settings, user style sheets)

supplemental content

additional content that illustrates or clarifies the primary content

synchronized media

technology (Web content)

mechanism for encoding instructions to be rendered, played or executed by user agents

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language

text alternative

Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. Programmatically associated text is text whose location can be programmatically determined from the non-text content.

platform event that occurs when the trigger stimulus of a pointer is released

The up-event may have different names on different platforms, such as "touchend" or "mouseup".

used in an unusual or restricted way

any software that retrieves and presents Web content for users

user-controllable

data that is intended to be accessed by users

user interface component

a part of the content that is perceived by users as a single control for a distinct function

user inactivity

any continuous period of time where no user actions occur

The method of tracking will be determined by the web site or application.

a time-based presentation that contains only video (no audio and no interaction)

object in which the user agent presents content

visually customized

the font, size, color, and background can be set

a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

This section contains a listing of common user interface component input purposes. The terms below are not keywords that must be used, but instead represent purposes that must be captured in the taxonomy adopted by a webpage. Where applicable, authors mark up controls with the chosen taxonomy to indicate the semantic purpose. This provides the potential for user agents and assistive technologies to apply personalized presentations that can enable more people to understand and use the content.

The list of input type purposes is based on the control purposes defined in the HTML 5.2 Autofill field section, but it is important to understand that a different technology may have some or all of the same concepts defined in its specification and only the concepts that are mapped to the meanings below are required.

The following input control purposes are intended to relate to the user of the content and pertain only to information related to that individual.

name - Full name

honorific-prefix - Prefix or title (e.g., "Mr.", "Ms.", "Dr.", "Mlle")

given-name - Given name (in some Western cultures, also known as the first name)

additional-name - Additional names (in some Western cultures, also known as middle names, forenames other than the first name)

family-name - Family name (in some Western cultures, also known as the last name or surname)

honorific-suffix - Suffix (e.g., "Jr.", "B.Sc.", "MBASW", "II")

nickname - Nickname, screen name, handle: a typically short name used instead of the full name

organization-title - Job title (e.g., "Software Engineer", "Senior Vice President", "Deputy Managing Director")

username - A username

new-password - A new password (e.g., when creating an account or changing a password)

current-password - The current password for the account identified by the username field (e.g., when logging in)

organization - Company name corresponding to the person, address, or contact information in the other fields associated with this field

street-address - Street address (multiple lines, newlines preserved)

address-line1 - Street address (one line per field, line 1)

address-line2 - Street address (one line per field, line 2)

address-line3 - Street address (one line per field, line 3)

address-level4 - The most fine-grained administrative level, in addresses with four administrative levels

address-level3 - The third administrative level, in addresses with three or more administrative levels

address-level2 - The second administrative level, in addresses with two or more administrative levels; in the countries with two administrative levels, this would typically be the city, town, village, or other locality within which the relevant street address is found

address-level1 - The broadest administrative level in the address, i.e., the province within which the locality is found; for example, in the US, this would be the state; in Switzerland it would be the canton; in the UK, the post town

country - Country code

country-name - Country name

postal-code - Postal code, post code, ZIP code, CEDEX code (if CEDEX, append "CEDEX", and the dissement, if relevant, to the address-level2 field)

cc-name - Full name as given on the payment instrument

cc-given-name - Given name as given on the payment instrument (in some Western cultures, also known as the first name)

cc-additional-name - Additional names given on the payment instrument (in some Western cultures, also known as middle names, forenames other than the first name)

cc-family-name - Family name given on the payment instrument (in some Western cultures, also known as the last name or surname)

cc-number - Code identifying the payment instrument (e.g., the credit card number)

cc-exp - Expiration date of the payment instrument

cc-exp-month - Month component of the expiration date of the payment instrument

cc-exp-year - Year component of the expiration date of the payment instrument

cc-csc - Security code for the payment instrument (also known as the card security code (CSC), card validation code (CVC), card verification value (CVV), signature panel code (SPC), credit card ID (CCID), etc)

cc-type - Type of payment instrument

transaction-currency - The currency that the user would prefer the transaction to use

transaction-amount - The amount that the user would like for the transaction (e.g., when entering a bid or sale price)

language - Preferred language

bday - Birthday

bday-day - Day component of birthday

bday-month - Month component of birthday

bday-year - Year component of birthday

sex - Gender identity (e.g., Female, Fa'afafine)

url - Home page or other Web page corresponding to the company, person, address, or contact information in the other fields associated with this field

photo - Photograph, icon, or other image corresponding to the company, person, address, or contact information in the other fields associated with this field

tel - Full telephone number, including country code

tel-country-code - Country code component of the telephone number

tel-national - Telephone number without the country code component, with a country-internal prefix applied if applicable

tel-area-code - Area code component of the telephone number, with a country-internal prefix applied if applicable

tel-local - Telephone number without the country code and area code components

tel-local-prefix - First part of the component of the telephone number that follows the area code, when that component is split into two components

tel-local-suffix - Second part of the component of the telephone number that follows the area code, when that component is split into two components

tel-extension - Telephone number internal extension code

email - E-mail address

impp - URL representing an instant messaging protocol endpoint (for example, "aim:goim?screenname=example" or "xmpp:fred@example.net")

This section shows changes for WCAG 2.1 since its publication as a W3C Recommendation. These changes are also recorded as errata.

Changes since the W3C Recommendation of 05 June 2018:

In the Status of This Document the paragraph beginning "This document has been reviewed by W3C Members..." appears twice. The first instance of this paragraph has been removed.

In the Introduction, several (but not all) references to "WCAG 2.0" has been changed to "WCAG 2.1".

In the 0.5.2 Numbering in WCAG 2.1, the words "critera" and "ccriteria" have been changed to "criteria".

In 1.4.10 Reflow, the first note had a supernumary "Note" indicator which has been removed.

In 1.4.13 Content on Hover or Focus, the word "dismissable" has been changed to "dismissible".

In 4. Robust, repetition of the word "by" has been removed.

In 5.2.2 Full pages, the third note began with "New" which has been removed.

In 5.3.1 Required Components of a Conformance Claim the editorial note "In WCAG 2.0 this was a dated URI, which may need to be adjusted when this becomes a Rec." has been removed.

In the definition for keyboard interface, the second (of three) note has been changed to be an example of the first note, leaving only two actual notes.

In the definition for technology, the third note has been changed to be an example.

In 7. Input Purposes for User Interface Components, the word "county" has been changed to "country".

In 1.3.4 Orientation, the note referencing "binary display orientation" has been clarified to read "content is not necessarily restricted to landscape or portrait display orientation".

In a note in the definition of accessibility supported, references to "Conformance Criterion" were changed to "Conformance Requirement".

In the definition of relative luminance, the red threshold was updated from 0.03928 to 0.04045.

In 4.1.1 Parsing one note was deleted, and two notes were added, including: "This Success Criterion should be considered as always satisfied for any content using HTML or XML."

The full commit history to WCAG 2.1 is available.

This section is non-normative.
Additional information about participation in the Accessibility Guidelines Working Group (AG WG) can be found on the Working Group home page.

Jake Abma (Invited Expert)

Shadi Abou-Zahra (W3C)

Chuck Adams (Oracle Corporation)

Amani Ali (Nomensa)

Jim Allan (Invited Expert)

Paul Adam (Deque Systems, Inc.)

Christopher Auclair (VitalSource | Ingram Content Group)

Jon Avila (Level Access)

Tom Babinszki (IBM Corporation)

Bruce Bailey (U.S. Access Board)

Renaldo Bernard (University of Southampton)

Chris Blouch (Level Access)

Denis Boudreau (Deque Systems, Inc.)

Judy Brewer (W3C)

Shari Butler (Pearson plc)

Thaddeus Cambron (Invited Expert)

Alastair Campbell (Nomensa)

Laura Carlson (Invited Expert)

Louis Cheng (Google)

Pietro Cirrincione (Invited Expert)

Vivienne Conway (Web Key IT Pty Ltd)

Michael Cooper (W3C)

Jennifer Delisi (Invited Expert)

Romain Deltour (DAISY Consortium)

Wayne Dick (Knowbility, Inc)

Chaohai Ding (University of Southampton)

Kim Dirks (Thomson Reuters)

Shwetank Dixit (BarrierBreak Technologies)

Anthony Doran (TextHelp)

E.A. Draffan (University of Southampton)

Eric Eggert (W3C)

Michael Elledge (Invited Expert)

David Fazio (Invited Expert)

Wilco Fiers (Deque Systems, Inc.)

Detlev Fischer (Invited Expert)

John Foliot (Deque Systems, Inc.)

Matt Garrish (DAISY Consortium)

Alistair Garrison (Level Access)

Michael Gower (IBM Corporation)

Jon Gunderson

Markku Hakkinen (Educational Testing Service)

Katie Haritos-Shea (Knowbility, Inc)

Andy Heath (Invited Expert)

Shawn Henry (W3C)

Thomas Hoffman (Educational Testing Service)

Sarah Horton (The Paciello Group, LLC)

Stefan Johansson (Invited Expert)

Marc Johlic (IBM Corporation)

Rick Johnson (VitalSource | Ingram Content Group)

Crystal Jones (Microsoft Corporation)

Andrew Kirkpatrick (Adobe)

John Kirkwood (Invited Expert)

Jason Kiss (Department of Internal Affairs, New Zealand Government)

Maureen Kraft (IBM Corporation)

JaEun Ku (University of Illinois at Urbana-Champaign)

Patrick Lauke (The Paciello Group, LLC)

Shawn Lauriat (Google, Inc.)

Steve Lee (Invited Expert)

Alex Li (Microsoft Corporation)

Chris Loiselle (Invited Expert)

Greg Lowney (Invited Expert)

Adam Lund (Thomson Reuters)

David MacDonald (Invited Expert)

Erich Manser (IBM Corporation)

Kurt Mattes (Deque Systems, Inc.)

Scott McCormack (Level Access)

Chris McMeeking (Deque Systems, Inc.)

Jan McSorley (Pearson plc)

Neil Milliken (Unify Software and Solutions)

Rachael Montgomery (Invited Expert)

Mary Jo Mueller (IBM Corporation)

Brooks Newton (Thomson Reuters)

James Nurthen (Oracle Corporation)

Joshue O Connor (Invited Expert)

Sailesh Panchang (Deque Systems, Inc.)

Charu Pandhi (IBM Corporation)

Kim Patch (Invited Expert)

Melanie Philipp (Deque Systems, Inc.)

Mike Pluke (Invited Expert)

Ian Pouncey (The Paciello Group, LLC)

Ruoxi Ran (W3C)

Stephen Repsher (Invited Expert)

Jan Richards (Invited Expert)

John Rochford (Invited Expert)

Marla Runyan (Invited Expert)

Stefan Schnabel (SAP SE)

Ayelet Seeman (Invited Expert)

Lisa Seeman-Kestenbaum (Invited Expert)

Glenda Sims (Deque Systems, Inc.)

Avneesh Singh (DAISY Consortium)

David Sloan (The Paciello Group, LLC)

Alan Smith (Invited Expert)

Jim Smith (Unify Software and Solutions)

Andrew Somers (Invited Expert)

Adam Solomon (Invited Expert)

Jaeil Song (National Information Society Agency (NIA))

Jeanne Spellman (The Paciello Group, LLC)

Makoto Ueki (Invited Expert)

Jatin Vaishnav (Deque Systems, Inc.)

Gregg Vanderheiden (Raising the Floor)

Evangelos Vlachogiannis (Fraunhofer Gesellschaft)

Kathleen Wahlbin (Invited Expert)

Can Wang (Zhejiang University)

Léonie Watson (The Paciello Group, LLC)

Jason White (Educational Testing Service)

Mark Wilcock (Unify Software and Solutions)

Paul Adam, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries Arditi, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick Boland, Denis Boudreau, Patrice Bourlon, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Ben Caldwell, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, Darcy Clarke, James Coltham, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Iyad Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Karl Groves, Loretta Guarino Reid, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn Houtepen, Carlos Iglesias, Richard Ishida, Jonas Jacek, Ian Jacobs, Phill Jenkins, Barry Johnson, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito Kidachi, Ken Kipness, Johannes Koch, Marja-Riitta Koivunen, Preety Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, N Maffeo, Mark Magennis, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, Liam McGee, Jens Oliver Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Charles F. Munat, Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Devarshi Pant, Nigel Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, Neil Soiffer, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Gian Wild, David Wooley, Wu Wei, Kenny Zhang, Leona Zumbo.

This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and now under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services or the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

# data[].attributes.attachment_link.title
Web Content Accessibility Guidelines (WCAG) 2.1

# data[].attributes.attachment_link.description
Web Content Accessibility Guidelines (WCAG) 2.1 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.

# data[].attributes.body
Each team shares one key insight about accessibility considerations and one challenge they anticipate in implementation. Discuss how planning time management affected their output quality.

# data[].attributes.body
Individual reflection: What are the three most important accessibility features you must include in your materials? How will your team approach the actual creation phase? What additional resources do you need?

# data[].attributes.body
Preview the implementation phase and timeline. Discuss available resources and support systems for the actual creation of video, case study, and infographic materials.

# data[].attributes.body
Research and document three examples of AI translation errors with cultural or contextual significance. Prepare brief analysis of why each error occurred and its impact.

# data[].attributes.attachment_link.title
Worst AI (and human) translation mistakes spotted by localization pros

# data[].attributes.attachment_link.description
Discover our funniest AI mistranslations—from “testiculations” to “milk weeks”—and why human post-editing is still vital for global brands.

# data[].attributes.body
Complete online WCAG 2.1 AA guidelines review module. Take notes on guidelines most relevant to video, PDF, and infographic creation. Prepare summary for next class.

# data[].attributes.attachment_link.readable_text
Accessibility skills are increasingly in demand. With this course, you can build your accessibility skills and immediately apply what you learn in practice.
Ms. Natalia Amelina, UNESCO Institute for Information Technologies in Education (IITE)

The "Introduction to Web Accessibility" online course provides the foundation you need to make your digital technology accessible, so that it:

works well for people with disabilities

meets international standards

enhances the user experience for everyone

achieves goals

Accessibility is essential to create high-quality apps, websites, and other digital content - and to not exclude people from using your products and services.

Page Contents

Who the course is for

Well worth [it] to reassess my #a11y knowledge. HINT: I learned a few things I didn't know.
Todd, Web Dev 21+ years #A11y
I would recommend anyone who creates #a11y training to join the course and/or integrate the lessons therein. Very well constructed!
Damian Sian, Director of Web Accessibility

The course is designed for technical and non-technical learners, including:

developers

designers

content authors

project managers

And also:

students

instructors

professionals

people with disabilities

What you get from the course

The course is structured so that you can focus on the topics that you are most interested in. Optional activities and additional materials provide more learning on specific topics.

For example, you can choose to focus on:

Coding web applications to meet international W3C standards.

Designing interfaces to meet the needs of people with disabilities, including older users.

Writing a business case to present to management.

Advocating for accessibility by understanding real-life experiences of how accessibility is essential for some, and useful for all.

Managing accessibility in projects and in organizations.

Checking web pages for basic accessibility issues and improving accessibility.

We encourage you to go through the whole course, even if you focus more on some topics.

Course content (syllabus)

The course covers principles from the World Wide Web Consortium (W3C) Web Accessibility Initiative's (WAI) Web Content Accessibility Guidelines (WCAG), and much more:

What is Web Accessibility (2 sections) - challenges the way you may approach accessibility.

People and Digital Technology (5 sections) - gives you the "why" behind the what you need to do for accessibility.

Business Case and Benefits (2 sections) - explains how accessibility can expand market reach, demonstrate social responsibility, drive innovation, and minimize legal risk.

Principles, Standards, and Checks (5 sections) - guides you through understanding accessibility requirements and checking for accessibility barriers (also called evaluating or testing for errors or bugs) - with non-technical and technical guidance; provides optional material for learning more about coding accessibly.

Getting Started with Accessibility (2 sections) - explains approaches for integrating accessibility into your design and development processes; provides tips for getting started with accessibility right away.

More "What you'll learn" and syllabus is in the edX course page.

Duration

It's easy to follow and complete. You can do it over several sessions at your own pace.
Laiya Lee 李荔雅
The nerdy gurl next door

The course is designed to take about 16-20 hours to complete for most people. It is listed as 4 weeks of 4-5 hours effort per week.

It is self-paced so you can complete it in a shorter or longer time frame.

This course will be available on the edX platform through at least June 2023. We expect an updated version of this course to be available long term.

Cost: Free, optional certificate

The course is free. The audit option gives you access to all of the content.

Optionally, you can choose to get a Verified Certificate for $99 USD to demonstrate successful course completion.

The Certificate can be printed, listed in resumes, and linked to from online profiles.

You can start auditing the course now, and later choose to get a Verified Certificate.
(For information about edX certificate verification and accessibility, see: edX Help Center Accessibility pages.)
Enroll in the course on edX ← log in to edX or create edX account

Video excerpts from the course

From Module 1, on how accessibility impacts the lives of people interacting in the digital world:

From Module 4, on designing and developing accessibly, and checking (evaluating or testing) for accessibility:

What people are saying about the course and survey results

Some more things that developers and others are tweeting about the course:

I just enrolled in this accessibility course and I watched some short clips (Module 1), and it made an impact on me.
I will work from now on accessibility improvements thinking about these real people, not just because 'the law', or because you 'should'
David Corbacho Roman. Señor Developer... JavaScript, React, Apollo, GraphQL, Next.js, Edge networking.

'Disability is about design. Bad design is disabling.'
The course on web accessibility by the @w3c_wai is filled with eye-opening arguments and concepts. Great job @shawn_slh and team!
Join the course!
Carlos Muncharaz. Front-end Developer.

I highly recommend this course for anybody wanting to learn about digital accessibility. It's got a lot of great info and a relatively small time commitment.
Justin Yarbrough. Blind. Digital #a11y specialist. #AvGeek.

Post-course survey responses (as of December 2022) include:

Have your skills/knowledge increased as a result of the course?
96% Yes.

Did you learn what you were expecting to learn?
90% Satisfied or Very satisfied.

How likely is it that you will be able to apply the skills that you learned in this course in your everyday work?
96% Likely or Very likely.

Provided by

Shadi (W3C) and Natalia (UNESCO) introduce the course:

The course is provided by the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) and the United Nations Educational, Scientific and Cultural Organization (UNESCO) Institute for Information Technologies in Education (IITE).

This unique course is based on the open curricula from the W3C WAI Education and Outreach Working Group (EOWG). It brings together international expert trainers from Deque, Infoaxia, Intopia, Knowbility, The Paciello Group ( TPG), Web Key IT, and W3C WAI.

Course Manager and Development Lead:

Shadi Abou-Zahra

Course Trainers:

Learn more from the edX course page Enroll in the course on edX ← log in to edX or create edX account

Alternatives for the video on this page

The course introduction video is also available on W3C servers: video for modern browsers and video mp4 file. Visual description:

Opening and closing scene has:

Two people at laptop smiling.

5 icons: hand, eye, brain in head, ear, speech/sound waves from mouth.

Most of the video is of Shadi and Natalia sitting by a desk.

There are a few other scenes for visual interest, not needed to understand the content.

Transcript:
Shadi: I'm Shadi Abou-Zahra, Accessibility Strategy and Technology Specialist at W3C, the World Wide Web Consortium.

Natalia: I'm Natalia Amelina, Senior National Project Officer in Education at the UNESCO Institute for Information Technologies in Education.

Shadi: Join us in this course to learn the fundamental skills and key resources that are becoming increasingly important across digital professions.

Natalia: In according with statistics, people with disabilities can make up around 15% of the population - and the United Nations Convention on the Rights of Persons with Disabilities recognizes access to information as a human right. And you may know that this Convention was ratified by 180 countries all over the world, very likely including your country too.

Shadi: In this course you will learn how people with disabilities use the web including different types of assistive technologies and adaptive strategies.

Natalia: You will also learn how web accessibility improves user experience of older people, people using mobile devices, and essentially for everyone.

Shadi: And, of course, you'll also learn all about the international standards from W3C - and training materials and learn first steps in creating accessible web content.

Natalia: This course was designed for technical and non-technical people. If you work with digital technologies this course is ideal for you to get started.

Please share your ideas, suggestions, or comments via e-mail to the publicly-archived list wai@w3.org or via GitHub.

Back to Top

# data[].attributes.attachment_link.title
Digital Accessibility Foundations - Free Online Course

# data[].attributes.attachment_link.description
Accessibility skills are increasingly in demand. With this course, you can build your accessibility skills and immediately apply what you learn in practice.

# data[].attributes.body
Create practice accounts and explore basic features of DeepL, Canva, and Google Slides. Document any accessibility features you discover in each platform.

# data[].attributes.body
Find and bookmark 2-3 examples of AI translation tools being used in African markets or other global contexts. Prepare to share findings with your team in the next session.

# data[].attributes.attachment_link.title
Leading, not lagging: Africa’s gen AI opportunity

# data[].attributes.attachment_link.description
Gen AI can create significant value across sectors, and Africa is poised to leapfrog other regions to capitalize on this transformative technology.