Table to do a quickscan on which points Drupal is compliant to ATAG 2.0 (draft version 21 July 2011) and which points needs work.
Notes:
- This is a scan on Drupal 7 core modules, but implementation of ATAG is focused on Drupal 8
- The new initiatives in Drupal 8 (configuration management, web services, design, multilingual and html5), have an impact on Drupal 8 ATAG compliance
- There is an ungoing initiative for WYSIWYG in core, that impacts ATAG as well.
- ATAG 2.0 is still in draft. Final version is foreseen August 2012, feedback from Drupal developers is welcome
- examples of implementations in Drupal is welcomed for implementation reports, i.e.10-6-2011
- In this text is the general term authoring tool replaced by Drupal
ATAG 2.0
PART A. Make the authoring tool user interface accessible
- A.1. Drupal user interfaces must follow applicable accessibility guidelines
- A.2. Editing-views must be perceivable
- A.3. Editing-views must be operable
- A.4. Editing-views must be understandable
PART B. Support the production of accessible content
- B.1. Fully automatic processes must produce accessible content
- B.2. Authors must be supported in producing accessible content
- B.3. Authors must be supported in improving the accessibility of existing content
- B.4. Authoring tools must promote and integrate their accessibility features
ATAG 2.0 | Drupal compliance |
---|---|
PART A. Make the Drupal user interface accessible |
|
Part A Conformance Applicability Notes:
|
|
PRINCIPLE A.1: Drupal user interfaces must follow applicable accessibility guidelines |
|
Guideline A.1.1: (For the Drupal user interface) Ensure that web-based functionality is accessible.Rationale: When authoring tools (or parts of authoring tools) are web-based, conforming to WCAG 2.0 will facilitate access by all authors, including those using assistive technologies. |
|
A.1.1.1 Web-Based Accessible (WCAG):Web-based Drupal user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
Implementing WCAG 2.0 level AA is a goal for Drupal 8 |
Guideline A.1.2: (For the Drupal user interface) Ensure that non-web-based functionality is accessible.Rationale: When authoring tools (or parts of authoring tools) are non-web-based, following existing accessibility guidelines and implementing communication with platform accessibility services facilitates access by all authors, including those using assistive technologies. |
|
A.1.2.1 Accessibility Guidelines:Non-web-based Drupal user interfaces follow user interface accessibility guidelines for the platform. (Level A)
|
|
A.1.2.2 Platform Accessibility Services:Non-web-based authoring tools implement communication with platform accessibility services. (Level A)
|
|
PRINCIPLE A.2: Editing-views must be perceivable |
|
Guideline A.2.1: (For the Drupal user interface) Make alternative content available to authors.Rationale: Some authors require access to alternative content in order to interact with the web content that they are editing. |
|
A.2.1.1 Text Alternatives for Rendered Non-Text Content:If an editing-view renders non-text content with programmatically associated text alternatives, then the text alternatives can be programmatically determined. (Level A) |
OK For Imagefield: Alt text field is accessible |
A.2.1.2 Alternatives for Rendered Time-Based Media:If an editing-view renders time-based media, then at least one of the following is true: (Level A)
|
timebased content n/a in Drupal 7 core will have impact for Drupal 8 html5 media |
Guideline A.2.2: (For the Drupal user interface) Editing-view presentation can be programmatically determined.Rationale: Some authors need access to details about the editing-view presentation, via their assistive technology, when that presentation is used to convey status information (e.g. underlining misspelled words) or provide information about how the end user will experience the web content being edited. |
|
A.2.2.1 Editing-View Status Information:If an editing-view modifies the presentation to convey status information, then that status information can be programmatically determined. Status information conveyed by modifying the presentation of editing-views may include, but is not limited to, spelling, grammar and syntax errors. (Level A) |
|
A.2.2.2 Access to Rendered Text Properties:If a text property is both rendered and editable and the text property is supported by the implemented platform accessibility service, then the property is programmatically determinable. (Level A) |
|
PRINCIPLE A.3: Editing-views must be operable |
|
Guideline A.3.1: (For the Drupal user interface) Provide keyboard access to authoring features. [Implementing A.3.1]Rationale: Some authors with |
|
A.3.1.1 Keyboard Access (Minimum):All functionality of Drupal is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
|
|
A.3.1.2 No Keyboard Traps:Keyboard traps are prevented as follows: (Level A)
|
|
A.3.1.3 Efficient Keyboard Access:The Drupal user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access . (Level AA) |
|
A.3.1.4 Keyboard Access (Enhanced):All functionality of Drupal is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA) |
|
A.3.1.5 Customize Keyboard Access:Keyboard access to Drupal can be customized. (Level AAA) |
|
A.3.1.6 Present Keyboard Commands:Drupal user interface components can be presented with any associated keyboard commands. (Level AAA) |
|
Guideline A.3.2: (For the Drupal user interface) Provide authors with enough time.Rationale: Some authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or that require fast reaction speeds, such as clicking on a moving target. |
|
A.3.2.1 Auto-Save (Minimum):If Drupal includes authoring session time limits, then Drupal can be set to automatically save web content edits made using Drupal before the session time limits are reached. (Level A) |
Drupals standard session limit is set in settings.php to 23 days (ini_set('session.cookie_lifetime', 2000000);). Is that a time limit that needs an autosave function? |
A.3.2.2 Timing Adjustable:If a time limit is set by Drupal, then at least one of the following is true: (Level A)
|
OK (f) |
A.3.2.3 Static Pointer Targets: Drupal user interface components that accept |
|
A.3.2.4 Content Edits Saved (Extended):Drupal can be set to automatically save web content edits made using Drupal. (Level AAA) |
not implemented, contributed modules: http://drupal.org/project/autosave and http://drupal.org/project/draft, |
Guideline A.3.3: (For the Drupal user interface) Help authors avoid flashing that could cause seizures.Rationale: Flashing can cause seizures in authors with photosensitive seizure disorder. |
|
A.3.3.1 Static View Option:Editing-views that render visual time-based content can be paused and can be set to not play automatically. (Level A) |
|
Guideline A.3.4: (For the Drupal user interface) Enhance navigation and editing via content structure.
|
|
A.3.4.1 Navigate By Structure:If editing-views expose the markup elements in the web content being edited, then the markup elements (e.g. source code, content renderings, etc.) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA) |
|
A.3.4.2 Navigate by Programmatic Relationships:If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. Depending on the web content technology and the nature of Drupal, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships. (Level AAA) |
|
Guideline A.3.5: (For the Drupal user interface) Provide text search of the content.
|
|
A.3.5.1 Text Search:Editing-views enable text search, such that all of the following are true: (Level AA)
|
|
Guideline A.3.6: (For the Drupal user interface) Manage preference settings.
|
|
A.3.6.1 Independence of Display:If Drupal includes display settings for editing-views, then Drupal allows authors to adjust these settings without affecting the web content to be published. (Level A) |
|
A.3.6.2 Save Settings:If Drupal includes display and/or control settings, then these settings can be saved between authoring sessions. (Level AA) |
|
A.3.6.3 Apply Platform Settings:Drupal respects changes in platform display and control settings made by authors. (Level AA) |
|
A.3.6.4 Multiple Sets:If Drupal includes display and/or control settings, then authors can save and reload multiple sets of these settings. (Level AAA) |
|
A.3.6.5 Assistance with Preferences:If Drupal includes display and/or control settings, then Drupal includes a mechanism to help authors configure these settings. (Level AAA) |
|
Guideline A.3.7: (For the Drupal user interface) Ensure that previews are as accessible as existing user agents.
|
|
A.3.7.1 Preview (Minimum):If a preview is provided, then at least one of the following is true: (Level A)
|
|
A.3.7.2 Preview (Enhanced):If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA) |
|
PRINCIPLE A.4: Editing-views must be understandable |
|
Guideline A.4.1: (For the Drupal user interface) Help authors avoid and correct mistakes.Rationale: Some authors with disabilities may be more susceptible to input errors due to factors such as difficulty making fine movements and speech recognition system errors. |
|
A.4.1.1 Content Changes Reversible (Minimum):For authoring actions, one of the following is true: (Level A)
|
Is this changes within a node-editing mode before save, and/or is this related to node revisions? Node-editing : implemented in WYSIWYG buttons 'undo' and 'redo', not in other fields or formats Node revision: node revision or warning needed. Not on by default |
A.4.1.2 Setting Changes Reversible:If actions modify authoring tool settings, then one of the following is true: (Level A)
|
This seems to need a rewrite of the admin interface of Drupal as many settings doesn't provide a warning or reversible mechanism that settings will be overwritten. |
A.4.1.3 Content Changes Reversible (Enhanced):Authors can sequentially reverse a series of reversible authoring actions. (Level AAA)
|
|
Guideline A.4.2: (For the Drupal user interface) Document the user interface including all accessibility features.Rationale: Some authors may not be able to understand or operate the Drupal user interface without proper accessible documentation. |
|
A.4.2.1 Document Accessibility Features:All features of Drupal that must be present to meet Part A of ATAG 2.0 (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)
|
|
A.4.2.2 Document All Features:Drupal includes documentation for its author-level user interface features. (Level AA)
|
|
PART B: Support the production of accessible content |
|
Part B Conformance Applicability Notes:
|
|
PRINCIPLE B.1: Fully automatic processes must produce accessible content |
|
Guideline B.1.1: Ensure automatically specified content is accessible. [Implementing B.1.1]Rationale: If authoring tools automatically specify web content that is not accessible, then additional repair tasks are imposed on authors. |
|
B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG):Authors have the default option that, when web content is automatically generated for publishing after the end of an authoring session, it is accessible web content (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
|
Does this apply to the aggregator module (http://drupal.org/documentation/modules/aggregator), where the author can enter a rss-feed and the content is loaded into Drupal? Note 3 says Drupal is not responsible for third party feeds. But a) if there is accessible content in the rss-feed Drupal should preserve this (Guideline B.1.2) and b) due to WCAG 2.0, all third party content should be accessible, or within two working days. |
B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG):Authors have the default option that, when web content is automatically generated during an authoring session, then one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
|
|
Guideline B.1.2: Ensure accessibility information is preserved. [Implementing B.1.2]Rationale: Accessibility information is critical to maintaining comparable levels of accessibility between the input and output of web content transformations. |
|
B.1.2.1 Restructuring and Recoding Transformations (WCAG):If Drupal provides restructuring transformations or re-coding transformations, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
|
|
B.1.2.2 Optimizations Preserve Accessibility:If Drupal provides optimizing web content transformations then any accessibility information (WCAG) in the input is preserved in the output. (Level A). |
|
B.1.2.3 Text Alternatives for Non-Text Content are Preserved:If Drupal provides web content transformations that preserve non-text content in the output, then any web content technology of the output. (Level A). |
|
PRINCIPLE B.2: Authors must be supported in producing accessible content |
|
Guideline B.2.1: Ensure accessible content production is possible.Rationale: For the purposes of this document, WCAG 2.0 defines the accessible web content (WCAG) requirements. To support accessible web content production, at minimum, it must be possible to produce web content that conforms with WCAG 2.0 using Drupal. |
|
B.2.1.1 Accessible Content Possible (WCAG):If Drupal places restrictions on the web content that authors can specify, then those restrictions do not prevent WCAG 2.0 success criteria from being met.. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
semantic html is possible in text areas, but not in titles and other textfields. |
Guideline B.2.2: Guide authors to produce accessible content.
|
|
B.2.2.1 Accessible Option Prominence (WCAG):If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g. styling text), then accessible web content (WCAG) are at least as prominent as options that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
|
B.2.2.2 Setting Accessibility Properties (WCAG):If Drupal provides mechanisms to set web content properties (e.g. attribute values, etc.), then mechanisms are also provided to set web content properties related to accessibility information (WCAG): (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
|
|
B.2.2.3 Technology Decision Support:If Drupal provides the web content technology for publishing for which the authoring tool does not provide support for the production of accessible content, then both of the following are true: (Level A)
|
|
Guideline B.2.3: Assist authors with managing alternative content for non-text content.
|
|
B.2.3.1 Alternative Content is Editable (WCAG):Authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
|
B.2.3.2 Conditions on Automated Suggestions:During the authoring session, Drupal may only automatically suggest programmatically associated text alternatives for non-text content under the following conditions: (Level A)
|
|
B.2.3.3 Let User Agents Repair:Drupal avoids repairing programmatically associated user agents (e.g. do not use the image filename). (Level A) |
|
B.2.3.4 Save for Reuse:When authors enter programmatically associated text alternatives for non-text content, both of the following are true: (Level AAA)
|
|
Guideline B.2.4: Assist authors with accessible templates.Rationale: Providing accessible templates and other pre-authored content (e.g. clip art, synchronized media, widgets, etc.) can have several benefits, including: immediately improving the accessibility of web content being edited, reducing the effort required of authors, and demonstrating the importance of accessible web content (WCAG) . |
|
B.2.4.1 Accessible Template Options (WCAG):If Drupal provides templates, then there are accessible template (WCAG) range of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
|
|
B.2.4.2 Identify Template Accessibility (Minimum):If Drupal includes a template selection mechanism and provides any non-accessible template (WCAG) templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)
|
|
B.2.4.3 Author-Create Templates:If Drupal includes a template selection mechanism and allows authors to create new non-accessible templates (WCAG), then authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA)
|
|
B.2.4.4 Identify Template Accessibility (Enhanced):If Drupal provides any non-accessible templates (WCAG) template selection mechanism, then the non-accessible templates include accessibility warnings within the templates. (Level AAA) |
|
Guideline B.2.5: Assist authors with accessible pre-authored content. [Implementing B.2.5]Rationale: Providing accessible templates and other pre-authored content (e.g. clip art, synchronized media, widgets, etc.) can have several benefits, including: immediately improving the accessibility of web content being edited, reducing the effort required of authors, and demonstrating the importance of accessible web content (WCAG). |
|
B.2.5.1 Pre-Authored Content Selection Mechanism:If authors are provided with a selection mechanism for pre-authored content other than templates (e.g. clip art gallery, widget repository, design themes), then both of the following are true: (Level AA)
|
|
B.2.5.2 Pre-Authored Content Accessibility Status:If Drupal provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AAA) |
|
PRINCIPLE B.3: Authors must be supported in improving the accessibility of existing content |
|
Guideline B.3.1: Assist authors in checking for accessibility problems. [Implementing B.3.1]Rationale: Accessibility checking as an integrated function of Drupal helps make authors aware of web content accessibility problems during the authoring process, so they can be immediately addressed. |
|
B.3.1.1 Checking Assistance (WCAG):If Drupal provides authors with the ability to add or modify web content so that a WCAG 2.0 success criterion can be violated, then accessibility checking for that success criterion is provided (e.g. an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
|
|
B.3.1.2 Help Authors Decide:For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking), instructions are provided from the check that describe how to make the decision. (Level A) |
|
B.3.1.3 Help Authors Locate:For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking), the relevant content is identified to the authors. (Level A)
|
not implemented, contributed module: http://drupal.org/project/accessible_content |
B.3.1.4 Status Report:Authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA)
|
|
B.3.1.5 Programmatic Association of Results:Authoring tools can programmatically associate accessibility checking results with the web content that was checked. (Level AA) |
|
Guideline B.3.2: Assist authors in repairing accessibility problems. [Implementing B.2.3]Rationale: Repair as an integral part of the authoring process greatly enhances the utility of checking and increases the likelihood that accessibility problems will be properly addressed. |
|
B.3.2.1 Repair Assistance (WCAG):If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
|
not implemented |
PRINCIPLE B.4: Authoring tools must promote and integrate their accessibility features |
|
Guideline B.4.1: Ensure the availability of features that support the production of accessible content.Rationale: The accessible content support features will be more likely to be used if they are turned on and are afforded reasonable prominence within the Drupal user interface. |
|
B.4.1.1 Features Active by Default:All accessible content support features are turned on by default. (Level A) |
|
B.4.1.2 Option to Reactivate Features:If authors can turn off an accessible content support feature, then they can turn the feature back on. (Level A) |
|
B.4.1.3 Feature Deactivation Warning:If authors turn off an accessible content support feature, then Drupal informs them that this may increase the risk of content accessibility problems. (Level AA) |
implementation is needed for input formats, alt text (http://drupal.org/node/815144), overlay etc |
B.4.1.4 Feature Prominence:Accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors. (Level AA) |
|
Guideline B.4.2: Ensure that documentation promotes the production of accessible content.Rationale: Without documentation of the features that support the production of accessible content (e.g. prompts for text alternatives, accessibility checking tools), some authors may not be able to use them. Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors. |
|
B.4.2.1 Model Practice (WCAG):A documentation (e.g. markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices that meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria) |
|
B.4.2.2 Feature Instructions:Instructions for using the accessible content support features appear in the documentation. (Level A) |
|
B.4.2.3 Tutorial:A tutorial on an accessible authoring process that is specific to Drupal is provided. (Level AAA) |
|
B.4.2.4 Instruction Index:The documentation contains an index to the instructions for using the accessible content support features. (Level AAA) |
Comments
Discussion for D8 on Drupal.org
Adding link to more recent thread on this issue for Drupal 8 https://drupal.org/node/2034909
--
OpenConcept | Twitter @mgifford | Drupal Security Guide