Neue Infos rund um WCAG 2.0Neue Infos rund um WCAG 2.0Neue Infos rund um WCAG 2.0Neue Infos rund um WCAG 2.0
Eric Eggert, W3C/WAI, @yatil, w3.org/People/yatil
KonzepteKonzepte
Why is this important?
Related WCAG 2.0
resources
Technologies covered in thisTutorial:
CSS FontsCSS Transforms HTML5MathML WAI-ARIA
Images must have text alternatives that describe theinformation or function represented by the images. Thisensures that images can be used by people with variousdisabilities. This tutorial demonstrates how to provideappropriate text alternatives based on the purpose of theimage:
Informative images: Images that graphically representconcepts and information, typically pictures, photos andillustrations. The text alternative should be at least ashort description conveying the essential informationpresented by the image.
Decorative images: Provide a null text alternative (alt="") when the only purpose of an image is to addvisual decoration to the page, rather than to conveyinformation that is important to understanding thepage.
Functional images: The text alternative of an imageused as a link or as a button should describe thefunctionality of the link or button rather than the visual
Tutorials home Images Images Concepts
1
2
3
4
5
6
7
This is an Editor’s draft, for preview purposes only. Please see, and link to, released tutorials at w3.org/WAI/tutorials/.
Web Accessibility TutorialsGuidance on how to create websites that meet WCAG
Images ConceptsOn this page
Images Tutorial
Images Concepts
Informative Images
Decorative Images
Functional Images
Images of Text
Complex Images
Groups of Images
Image Maps
An alt Decision Tree
Tips and Tricks
All Tutorials
Page Structure DRAFT
Menus DRAFT
Images
Tables
GrundStrukturGrundStruktur
Associating labels explicitly
Hiding label text
Approach 1: Hiding the label element
Approach 2: Using aria-label
Approach 3: Using the title attribute
Note on hiding elements
Associating labels implicitly
Labelling buttons
Visual position of label text
Related WCAG 2.0 resources
Provide labels to identify all form controls, including text fields, checkboxes, radio buttons, anddrop-down menus. In most cases this is done by using the <label> element.
Labels need to describe the purpose of the form control. This section of the tutorial describeshow to provide labels that are properly associated with form controls. Later sections explainhow to provide instructions, validate user input, and provide feedback to help users completeyour form.
A label and a form control need to be associated with each other either implicitly or explicitly.Web browsers provide the label as a larger clickable area, for example, to select or activate thecontrol. It also ensures that assistive technology is able to refer to the correct label whenpresenting a form control.
Associating labels explicitly
Whenever possible, use the label element to explicitly associate text with form elements.The for attribute of the label must exactly match the id of the form control.
EXAMPLE:
First name:
Subscribe to newsletter
CODE SNIPPET: HTML
<label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname"><br>
<input type="checkbox" name="subscribe" id="subscribe">
<label for="subscribe">Subscribe to newsletter</label>
Hiding label text
Tutorials home Forms Labeling Controls
1
2
3
4
5
6
7
This is an Editor’s draft, for preview purposes only. Please see, and link to, released tutorials at w3.org/WAI/tutorials/.
Web Accessibility TutorialsGuidance on how to create websites that meet WCAG
Labeling ControlsOn this page
Forms Tutorial
Forms Concepts
Labeling Controls
Grouping Controls
Form Instructions
Validating Input
User Notifications
Multi-page Forms
Custom Controls
All Tutorials
Page Structure
DRAFT
Menus DRAFT
Images
Tables
Forms
Carousels DRAFT
SHARE
SHARE
StylingStyling
Vertical menu
Horizontal menu
Styling menu items
Menu feedback
Related WCAG 2.0 resources
With a consistent styling users are able to find menus more easily. There are two basic designpatterns that are commonly used on web sites: vertical and horizontal menus.
Regardless of the orientation, each menu item should have enough space so it doesn’t overlapother content on the page or gets cut off. Such items are a potential accessibility barrier,especially for users increasing the font size and can also be a problem when translating themenu into another language. Try to avoid line breaks or hyphenation in menu items as they areharder to understand.
Vertical menu
Ensure that the menu column is wide enough to accommodate all current and future menuitems.
EXAMPLE:
Home
Shop
SpaceBears
MarsCars
Contact
Horizontal menu
Horizontal menus should be positioned near the top of the screen so they are easier to find.
EXAMPLE:
Tutorials home Menus Menu Styling
1
2
3
4
This is an Editor’s draft, for preview purposes only. Please see, and link to, released tutorials at w3.org/WAI/tutorials/.
Web Accessibility TutorialsGuidance on how to create websites that meet WCAG
[APPROVED DRAFT]
Menu StylingOn this page
SHARE
SHARE
Menus Tutorial
Menu Concepts
Structure
Styling
Fly-out Menus
Applications Menus
All Tutorials
Page Structure
DRAFT
Menus DRAFT
Images
Tables
Forms
Carousels DRAFT
Funktionalität eines KarussellsFunktionalität eines Karussells
Position slides
Adding previous and next buttons
Announcing slides
Items navigation
Focusing carousel items
Putting it all together
Related WCAG 2.0 resources
Carusels display the one content item at a time while hiding the others. They allow users to
browse through them.
Position slides
If the JavaScript is enabled, a class active is added to the carousel region so we can
distinguish between that state and the non-JavaScript fallback. The slides are positioned
absolutely in the carousel, and the current slide is positioned frontmost using z-index.
CODE SNIPPET:
.active .slide {
display: none;
position: absolute;
top: 0;
left: 0;
border: none;
}
.slide.current {
display: block;
z-index: 500;
}
The outcome looks like this:
EXAMPLE:
Featured Articles:
Tutorials home Carousels Functionality
Status: This is not ready for detailed review. It is an in-progress, unapproved editor’s draft.
1
2
3
This is an Editor’s draft, for preview purposes only. Please see, and link to, released tutorials at w3.org/WAI/tutorials/.
Web Accessibility TutorialsGuidance on how to create websites that meet WCAG
[ROUGH DRAFT]
Functionality
On this page
SHARE
Carousels Tutorial
Carousel Concepts
Structure
Functionality
Animations
Complete code
example
All Tutorials
Page Structure
DRAFT
Menus DRAFT
Images
Tables
Forms
Carousels DRAFT
menüs für Anwendungenmenüs für Anwendungen
EXAMPLE:
Web application menus use the same basic structure as navigation menus: They often consist ofa horizontal menu bar and use fly-out functionality.
Some additional WAI-ARIA roles help users with assistive technology to operate those menus in away that is similar to the way they use menus in desktop software. When using those roles, thekeyboard interaction should be similar to desktop software as well: the tab key is used toiterate through the top-level items only, the up and down arrows are used to navigate the submenus.
Note that the keyboard behavior is not automatically changed when adding those roles, butneeds to be added using scripting. A detailed explanation on the WAI-ARIA attributes andkeyboard behavior can be found in the WAI-ARIA Authoring Practices document (draft) .
In addition to the aria-expanded and aria-haspopup attributes, the following roles areused in the example:
menubar: Represents a (usually horizontal) menu bar.menu: Represents a set of links or commands in a menu bar, it is used for the fly-outmenus.menuitem: Represents an individual menu item.
The markup has no links at all: It is a nested list with WAI-ARIA roles as the application would benon-functional without JavaScript available anyway.
Tutorials home Menus Web Application Menus
1
2
3
4
This is an Editor’s draft, for preview purposes only. Please see, and link to, released tutorials at w3.org/WAI/tutorials/.
Web Accessibility TutorialsGuidance on how to create websites that meet WCAG
[APPROVED DRAFT]
Web Application Menus
File Edit Format View Help
Menus Tutorial
Menu Concepts
Structure
Styling
Fly-out Menus
Applications Menus
All Tutorials
Page Structure
DRAFT
Menus DRAFT
Images
Tables
Forms
Carousels DRAFT
tutorialstutorialshttps://w3.org/WAI/tutorials
https://w3c.github.io/wai-tutorials/
Tips for getting startedTips for getting started
DesigningWritingDeveloping
http://w3c.github.io/wai-quick-start/
Evaluation Tools ListEvaluation Tools Listhttps://www.w3.org/WAI/ER/tools/
WCAG-EM Report ToolWCAG-EM Report Tool
WCAG-EM Report ToolWebsite Accessibility Evaluation Report GeneratorThis tool helps you generate a report according to the Website Accessibility Conformance Evaluation Methodology (WCAG-EM). It does not perform anyaccessibility checks. It helps you follow the steps of WCAG-EM, to generate a structured report from the input that you provide. It is designed for experiencedevaluators who know Web Content Accessibility Guidelines (WCAG) 2.0 and are somewhat familiar with WCAG-EM. For an introduction to WCAG-EM, see theWCAG-EM Overview.
Note: This tool does not automatically save the information that you enter. To save your data in a file locally on your computer, use Windows shortcut keysCtrl+S or Mac shortcut keys ⌘S to open the Save dialog. (Or the 'Save' link at the top of the page will open the Save Evaluation Report page and from therethe 'Save data file locally to your computer' link will open the Save dialog.)
How this tool works
Tips for using this tool
Feedback: We welcome ideas, bug reports, and comments via GitHub or e-mail to [email protected] (a publicly archived list) or [email protected] (a WAI staff-only list).
Status: Version 1.0, 26 Febuary 2015
Development Team: Shadi Abou-Zahra, W3C/WAI (Project Lead) and Wilco Fiers, accessibility.nl (Design and development). Contributors: Shawn Lawton Henry and the Education and Outreach Working Group.
Developed with support from the WAI-ACT Project, a project of the European Commission IST Programme.
[WAI Site Map] [Help with WAI Website] [Search] [Contacting WAI]Copyright © 2014 W3C (MIT, ERCIM, Keio, Beihang) Usage policies apply.
New Report Open Save Key Resources
Start 1. Define Scope 2. Explore Website 3. Select Sample 4. Audit Sample 5. Report Findings View Report
Next step: Define Scope
®
WCAG-EM Report ToolWCAG-EM Report Toolhttp://www.w3.org/WAI/eval/report-tool/#/
Heute:Heute:http://www.w3.org/WAI/WCAG20/quickref/
Customize this Quick ReferenceTechnologies:
Show HTML techniques and failuresShow CSS techniques and failuresShow SMIL techniques and failuresShow Client-side Scripting techniques and failuresShow Server-side Scripting techniques and failuresShow Flash techniques and failuresShow PDF techniques and failuresShow Silverlight techniques and failuresShow WAI-ARIA techniques and failures
Levels:Show Level A Success CriteriaShow Level AA Success CriteriaShow Level AAA Success Criteria
Sections:Show Sufficient Techniques and FailuresShow Advisory Techniques
Save Settings Option:Save these settings (requires cookies)
Customize with Settings Above
How to Meet WCAG 2.0A customizable quick reference to Web Content Accessibility Guidelines 2.0 requirements(success criteria) and techniques
Introduction[Hide Introduction]
This web page can be used as a checklist for WCAG 2.0. It provides:
All of the requirements (called "success criteria") from WebContent Accessibility Guidelines (WCAG) 2.0
Techniques to meet the requirements, which are linked to pageswith descriptions, code examples, browser and assistive technologysupport notes, and tests.Failures to avoid, which are linked to pages with descriptions,examples, and tests.
"Understanding" links to pages that explain the intent of theguideline or success criterion, how it helps people with differentdisabilities, key terms, and resources.
You can customize what is included in this page by selecting from theCustomize this Quick Reference section which Technologies, Levels ofsuccess criteria, and Sections of techniques you want to include.
For an introduction to WCAG, Techniques, and Understandingdocuments, see the WCAG Overview.
Note that even content that conforms at the highest level (AAA) will not beaccessible to individuals with all types, degrees, or combinations ofdisability, particularly in the cognitive language and learning areas. Authorsare encouraged to seek relevant advice about current best practice toensure that Web content is accessible, as far as possible, to thiscommunity.
About the TechniquesFor important information about the techniques, please see the Understanding Techniques for WCAG Success Criteria section of Understanding WCAG2.0.
Note: The basis for determining conformance to WCAG 2.0 is the success criteria, not the techniques. (The success criteria have 3-level numbering (0.0.0) and in thispage they are followed by a link "Understanding Success Criterion".) All techniques are informative; that means they are not required. There may be other techniquesbesides the ones listed here.
New Techniques and CommentsThe Techniques for WCAG 2.0 document is updated periodically, and anyone can submit techniques that will be considered for inclusion in an update. Please submitcorrections, updates, or new information related to techniques, failures, or other WCAG documentation to the WCAG Working Group, per the instructions forcommenting.
In Zukunft:In Zukunft:http://w3c.github.io/wai-wcag-quickref/
Status: This is an incomplete rough mockup of a redesign. The published version of the How to Meet WCAG 2.0 quick reference is at: www.w3.org/WAI/WCAG20/quickref/ More
[Mockup] How to Meet WCAG 2.0 A customizable quick reference to Web Content Accessibility Guidelines 2.0 requirements (success criteria) and techniques
About this Quick Reference
Principle 1 – PerceivableInformation and user interface components must be presentable to users in ways they can perceive.
1.1 Text AlternativesProvide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
1.1.1 Non-text Content — Level AAll non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations
listed below. Show full description Understanding 1.1.1
BACK TO TOP
1.2 Time-based MediaProvide alternatives for time-based media.
1.2.1 Audio-only and Video-only (Prerecorded) — Level AFor prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media
alternative for text and is clearly labeled as such: Show full description Understanding 1.2.1
BACK TO TOP
1.2.2 Captions (Prerecorded) — Level A
Hide Contents Filter
1.1 Text Alternatives
1.1.1 Non-text Content
1.2 Time-based Media
1.2.1 Audio-only and Video-only
(Prerecorded)
1.2.2 Captions (Prerecorded)
1.2.3 Audio Description or Media
Alternative (Prerecorded)
1.2.4 Captions (Live)
1.2.5 Audio Description
(Prerecorded)
1.2.6 Sign Language (Prerecorded)
1.2.7 Extended Audio Description
(Prerecorded)
1.2.8 Media Alternative
(Prerecorded)
1.2.9 Audio-only (Live)
1.3 Adaptable
1.3.1 Info and Relationships
1.3.2 Meaningful Sequence
1.3.3 Sensory Characteristics
1.4 Distinguishable
1.4.1 Use of Color
1.4.2 Audio Control
1.4.3 Contrast (Minimum)
1.4.4 Resize text
1.4.5 Images of Text
1.4.6 Contrast (Enhanced)
1.4.7 Low or No Background Audio
1. Perceivable
Show techniques for 1.1
SHARE
Show techniques for 1.1.1
SHARE
Show techniques for 1.2.1
SHARE
Showing all success criteria and all techniques. Link to this view
Mobile AccessibilityMobile Accessibilitytask forcetask force
WCAG WG & UAWG
http://www.w3.org/WAI/GL/mobile-a11y-tf/
Mobile Accessibility: How WCAG 2.0 andMobile Accessibility: How WCAG 2.0 andOther W3C/WAI Guidelines Apply to MobileOther W3C/WAI Guidelines Apply to Mobile
Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to MobileW3C First Public Working Draft 26 February 2015This version:
http://www.w3.org/TR/2015/WD-mobile-accessibility-mapping-20150226/Latest published version:
http://www.w3.org/TR/mobile-accessibility-mapping/Latest editor's draft:
http://w3c.github.io/Mobile-A11y-TF-Note/Editors:
Kim Patch, Redstart SystemsJeanne Spellman, W3CKathy Wahlbin, Interactive Accessibility
Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
AbstractThis document, “Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile” describes how the Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] andits principles, guidelines, and success criteria can be applied to mobile web content, mobile web apps, native apps, and hybrid apps using web components inside native apps. It providesinformative guidance, but does not set requirements. It also highlights the relevance of the User Agent Accessibility Guidelines 2.0 [UAAG20] in the mobile context.
This document is intended to become a Working Group Note and is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI).
Status of This DocumentThis section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of thistechnical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a First Public Working Draft by the Mobile Accessibility Task Force (Mobile A11Y TF) operating under the terms of its Work Statement under the joint coordination and reviewof the Web Content Accessibility Guidelines Working Group (WCAG WG) and the User Agent Accessibility Guidelines Working Group (UAWG), which is part of the Web Accessibility Initiative(WAI) of the World Wide Web Consortium (W3C). This document is intended to become a W3C Note.
Feedback on this draft is essential to the success of this guidance. The Mobile Accessibility Task Force asks in particular:
1. Is this document helpful in understanding the applicability of WCAG 2.0 and UAAG 2.0 to the mobile environment?2. Is the format of this information helpful for designers, developers and testers of content that can be viewed with mobile devices and in mobile apps? Is it useful for policymakers?3. In Appendix A, is listing relevant existing WCAG 2.0 techniques helpful for mobile content and mobile app developers?4. Are there additional accessibility needs in the mobile environment related to the WCAG principles that we should address?
Cognitive and Learning DisabilitiesCognitive and Learning DisabilitiesAccessibility Task ForceAccessibility Task Force
PFWG & WCAG WG
http://www.w3.org/WAI/PF/cognitive-a11y-tf/
Low vision AccessibilityLow vision Accessibilitytask forcetask force
„in Diskussion“
http://www.w3.org/WAI/GL/low-vision-a11y-tf/
Eric EggertEric Eggert
http://w3.org/People/yatil/
http://slides.com/yatil/atag-wcag-2015/
Top Related