- From: Boland Jr, Frederick E. <frederick.boland@nist.gov>
- Date: Sun, 28 Apr 2013 16:36:30 -0400
- To: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
done - to emphasize, this is just a start, and subject to change.. Thx Tim Boland NIST ________________________________________ From: Richards, Jan [jrichards@ocadu.ca] Sent: Friday, April 26, 2013 5:17 PM To: Boland Jr, Frederick E. Subject: RE: preliminary information on WordPress and Accessibility/ATAG2.0 Thanks Tim, this is a great start…any chance you could send it to the group? -Jan From: Boland Jr, Frederick E. [mailto:frederick.boland@nist.gov] Sent: April-24-13 11:23 AM To: Richards, Jan Subject: preliminary information on WordPress and Accessibility/ATAG2.0 As I told you, I would send something on WordPress this week, so here goes.. Just getting started on this exercise, organizing my thoughts.. I have limited time to work on this at the present so would appreciate any help.. Thanks in advance.. Information following is meant as a beginning to stimulate further discussion.. A possible next step is to actually follow the steps in the tests recently developed.. I understand that if we don’t have a bunch of YESs, we don’t want to include.. I see potential, but may not be there yet.. Hi, following is a list of Level A ATAG2.0 SC, with some comments in relation to WordPress, followed by some notes culled together on WordPress accessibility from references on the web. Overall, it appears that for Part A, WordPress is somewhat accessible but needs to go farther, and for Part B, it is possible for authors to create accessible content using WordPress but a lot of the initiative belongs to the author (WordPress needs to help more). So strictly speaking, many of the SCs may be "partially" satisfied but not completely satisfied (there is a "spectrum" of possibilities here, but strictly speaking most of them are NO at this point ). Not sure how to proceed at this point. Could you please help me on organizing this, as I have limited time to spend on it? Thanks.. I also wrote some earlier information on WordPress accessibility, although it may be outdated by now.. DISCLAIMER: BASED ON INCOMPLETE KNOWLEDGE AND SUBJECT TO REVISION.. A.1.1.1 – no (re: sentence following ADD MEDIA PANEL in notes following - violates WCAG SC2.1.1)? A.1.2.1 – possibly (depending on platform)? A.1.2.2 – possibly (depending on platform accessibility services )? A.2.1.1 – yes (re: "great HTML" comment following)? A.2.1.2 – no (re: autoplaying audio/video control comment in THEMES in notes following)? A.2.2.1 – not sure (re:any presence of status indicators)? A.3.1.1 – no (re: sentence following ADD MEDIA PANEL - dependence on mouse)? A.3.1.2 – no (re: focus comment follwoing ADD MEDIA PANEL discussion and other places in notes following)? A.3.2.1 – no (re: discussion at end of DIALOG/POPUP section in notes following)? A.3.2.2 – no (re: discussion in DIALOG/POPUP section in notes following)? A.3.2.3 – no (re: ADD MEDIA PANEL, DIALOG/POPUP, CUSTOM MENU, and other discussions in notes following)? A.3.3.1 – no (re: autoplaying audio/video control comment in THEMES in notes following)? A.3.6.1 – yes (re: documentation mentioned in notes following)? A.3.7.1 – yes (re: are previews provided)? A.4.1.1 – no (re: meaning of "all"re; documentation mentioned in notes following)? A.4.1.2 – no (re: ADD PANEL, THEMES, POPUP/DIALOG details in notes following)? A.4.2.1 – yes (re: documentation referenced in notes following)? B.1.1.1 – no (re: information in notes following)? B.1.1.2 – no (re: information in notes following)? B.1.2.1 – not sure (re: existence of transformations)? NOTE: STOPPED HERE B.1.2.2 – yes (not aware of any contradictory info to this)? B.1.2.3 – yes (not aware of any contradictory info to this)? B.1.2.4 – yes (not aware of any contradictory info to this)? B.2.1.1 – possibly no (re: discussion on ADD PANEL, DIALOG/POPUP, Custom Menu in notes following)? B.2.2.1 – possibly yes (in absence of any evidence to contrary)? B.2.2.2 – no (some accessibility properties not covered in notes following) B.2.3.1 – yes (in absence of any evidence to contrary) B.2.3.2 – pass by default (premise not true)? B.2.3.3 – pass by default (premise not true)? B.2.4.1 – no (re: discussion on THEMES, if THEMES are in fact templates, in notes following) B.3.1.1 – no (re: discussion/references in notes following) B.3.1.2 –yes by default (premise not true)? B.3.1.3 – yes by default (premise not true)? B.3.2.1 – no (no evidence that this is true (re: notes following)? B.4.1.1 – not sure but maybe no (re: notes following)? B.4.1.2 – yes by default (premise not true)? B.4.2.1 – yes (re: documentation references in notes following) B.4.2.2 – possibly yes (re: documentation references in notes following) NOTES FOLLOWING: GENERAL: Many of the accessibility limitations of WordPress can be easily overcome, with the right knowledge. In other words, in spite of the problems mentioned, accessibility can be enhanced. Most of the base HTML and functionality generated by WordPress is great, but there are a few issues as follows: empty searches do not return an error, default values for “more” links are not specific, and there are lots of redundant title attributes; all of these issues are fixable in themes. WordPress for web site editors may be defined in terms of dynamic editing, keyboard navigability, and change management. WordPress 3.5 removes tabindex, adds skiplinks, fixes tabbing order in numerous contexts, adds the ability to log out by keyboard, enables the proper labeling of numerous form fields, and allows the clearly visible focus of keyboard navigation. Furthermore, screen options are now much more easily found and used, giving better access to screen customizations and accessibility modes. WordPress accessibility can fix some problems, but not all. Not all accessibility issues are fixed in WordPress 3.5; bug reports continue to be submitted (for example, with Add Panel, Dialogs, and Custom Menus mentioned following). WordPress has documentation regarding accessibility at the following link: http://codex.wordpress.org/Accessibility under “Support” tab. In this documentation it is stated: “WordPress - with a high quality theme (reference themes directory) - works right out of the box to help you keep your site accessible. A great deal of the work is done for you but you still have to take the time and patience to maintain those accessibility standards when creating your content. NOTE that ATAG is not specifically mentioned under “resources” . The Make WordPress Accessible Group (with notes referenced following) is also mentioned in the documentation. This is the official blog for the WordPress accessibility group - dedicated to improving accessibility in core WordPress and related projects. The aim of this group is to provide accessibility suggestions, feedback and assistance to WordPress core, theme and plugin developers. Anyone can join in the discussions by logging into the blog using a WordPress.org username and password. One can also follow discussions via email or subscribe to feeds for both posts and comments. Additional information on WordPress accessibility is at: http://www.vocalbranding.com.au/these-are-a-few-of-my-favourite-themes-and-accessible-wordpress-plugins/ and at: http://bitly.com/bundles/o_6tfctf5qac/8 In summary, on the public side, WordPress makes very few mistakes, and these can be corrected by a theme or plug-in (mentioned following), but WordPress only controls a small percentage of the presentation of a web site. WordPress administration, though not perfect, is improving. The WP Accessible Project highlights plug-ins and themes that help accessibility at: http://wp-accessible.com. There appears to be momentum in the WordPress community at all levels to improve accessibility. Additional support for WordPress accessibility is at: http://en.support.wordpress.com/accessibility/ In sum, for a website to be accessible to individuals with disabilities, it seems that basic WordPress has much that is needed to facilitate the development of an accessible website, and it is not hard to take that further through the addition of plugins and good technique. Additional information is at: http://www.sitepoint.com/4-ways-to-make-your-wordpress-site-more-accessible/ THEMES In terms of accessibility problems with WordPress for web site visitors, there are inaccessible themes, as well as inherent problems in WordPress. Themes pose challenges, in that almost all of the public experience of a WordPress site comes from the theme in use, and most themes are not accessible; currently available themes are generally lacking a focus on accessibility. Finding accessible themes is very difficult; there is not a good way to find accessible themes. In other words, there may be many accessible WordPress themes around, but there is no easy way to find them. Searching for accessible themes will find some, but they need to be judged critically Building custom themes can be expensive, and customizing existing themes is not necessarily cheaper. For accessible themes, visit http://wp-accessible.org/themes/ to locate reviewed accessible themes. Also, audited accessibility tag may be coming to the WordPress theme repository, but it’s not there yet. The effort: http://make.wordpress.org/accessibilitiy/ is working to add an audited theme tag to the WordPress theme repository to help locate accessibility-ready themes. Self-labeling themes as accessible may give mixed results. The Cities Project: http://accessiblejoe.com/cities/ is working on building accessible WordPress themes. Additional comments on accessibility of WordPress themes is at: http://accessible.sprungmarker.de/. In these comments, it is pointed out that some accessibility issues for themes are: not enough contrast in colors, few improvements for keyboard users and you get no real information about user’s location within a web page. Another proposed set of changes would require controls for autoplaying audio/video in themes. The WordPress Theme Review Team provides and maintains documents as part of their task as WordPress Contributors and Developers for the WordPress Theme Directory. These documents and notes represent the guidelines for designing and developing WordPress Themes for the public as well as for WordPress Theme Directory standards and practices. As mentioned previously, information is proposed to be added to the Theme Review Guidelines to specially address accessibility for an accessibility audit (there are currently many quality guidelines but they don’t have to be part of an accessibility audit). The Theme Accessibility Audit provides an optional theme review for themes submitted to the wordpress.org Theme Repository. Submitted themes (or theme updates) that contain the tag accessibility-ready will undergo an independent, accessibility review after they have been approved for inclusion in the Theme Repository. Themes that pass this level of review successfully will be allowed to use the accessibility-ready tag. Authors of themes that fail will be asked to re-submit their themes without the accessibility-ready tag or make requested changes in order to meet the requirements. A first draft has been completed of Accessibility for Theme Developers, which addresses accessibility issues for those developing themes to consider from the beginning. This falls under the Make WordPress Documentation. Proposed ARIA enhancements may help in this area, as well. PLUG-INS In terms of using WordPress plug-ins, WordPress plug-ins are “all over the map” in terms of accessibility. There is little to no quality checking in the plug-in repository, and even if there was, checking for accessibility would be almost impossible to do. Extending WordPress via plug-ins is hazardous, and requires careful checking A WordPress accessibility plugin (found at: http://wordpress.org/extend/plugins/wp-accessibility/) can be installed and configured. This plug-in can remove redundant title attributes, enable skip links with WebKit, add skip links with user-defined targets, add language and text direction attributes, remove the target attribute from links, force a search page error on an empty search, remove tabindex from elements that are focusable, strip title attributes from images in content, add post titles to “read more” links, and add an outline to the :focus state for focusable elements. This plug-in cannot fix color contrast issues, correct forms to add labels or give meaningful errors, fix heading structures for screen reader navigation, give appropriate alt attributes to images, and correct for many other specialized circumstances. There are over 20,000 plug-ins currently in the repository. It cannot be assumed that most of them are accessible. Due to the nature of the Wordpress.org plug-in search engine, most of the results for ‘accessible’ do not relate to accessibility. Most plug-ins must be checked independently. There is also a WordPress PlugIn Directory (tag – accessibility) at: http://wordpress.org/extend/plugins/tags/accessibility Additional information is at: http://wordpress.org/extend/plugins/wp-accessibility/ (also mentioned previously) and at: http://make.wordpress.org/accessibility/useful-tools/. A WordPress Accessibility Plugin is at: http://make.wordpress.org/accessibility/wp-accessibility-plugin/ ADD MEDIA PANEL There are accessibility problems with the Add Media Panel in WordPress Version 3.5. It is not possible to select/deselect any of the media without using a mouse. The functionality primarily acts like a group of checkboxes – selecting one or multiple elements, with feedback that they have been selected. However, that is not how the functionality has actually been implemented – it’s a series of divs contained within an unordered list. There appears to be nothing to receive focus. There are links for each file, but the links appear empty although they are used to show the selected icon. These links are also initially invisible using CSS techniques that hide them from screen readers – hence the no tabbing into the images issue. When mouse users select an image they can update the attribute values for that image using the panel to the right – which updates its content automatically. Allowing keyboard users to quickly reach the attributes boxes would obviously be desirable – the alternative being tabbing through all the previously uploaded files. It is not possible to tab to the individual images to select them. This issue means that the functionality cannot be used by screen reader users, or by those who rely on keyboard-only interaction – either directly or via their assistive technology. Voice recognition users will also have a hard job – being forced to rely on mouse emulations if they are available. With a proposed ARIA solution, keyboard-only users can tab through the items in the media list and select/deselect using enter key. Also screen reader users appear to be getting some useful information but possibly only the newest versions can fully use this functionality. Maybe something like this will be included in 3.6 and/or 3.7. DIALOGS/POPUPS It seems there are an increasing number of areas in WordPress where dialogs or popup panels are used to alert the user about occurrences and perhaps demand some action from them. Examples include the Autosave/Post Locking dialogs, and Login Expiration. It is proposed to change the frequency that post locks are checked to 15 seconds when the user is active and 2 minutes when inactive, and add prominent warnings when somebody else is editing or when another user takes over. It is also proposed to improve the user experience when the login has / will expire, as proposed for WordPress 3.6. A suggested tactic is to integrate a “post savior” plugin into core. Some valuable enhancements that are on a possible plugin's roadmap (but not yet complete) would be: 1) alert properly on failed requests and lost connectivity, 2) block publish/save until login has been verified, and 3) establish pre-emptive notification. Other enhancements that may be useful include: 1) when a dialog opens, keyboard focus must be transferred into a meaningful object within the dialog – suggest a heading that explains purpose of dialog NOTE: this item can be given tabindex=0 to allow it to receive focus both by scripting and tabbing), 2) the purpose of the dialog should always be visible, 3) while the dialog is open, functionality is needed to cope with users tabbing beyond the controls/buttons in the dialog or reverse tabbing before the entry point (NOTE: tabbing can either cycle within dialog if it’s important that a user responds, or that tabbing outside the confines of a dialog closes the dialog), 4) whenever a dialog is closed, keyboard focus should be returned to somewhere sensible – maybe the link/button that opened dialog in the first place, or to the top of a new page if one is opened. CUSTOM MENUS There may also be an accessibility issue with custom menus in WordPress. It is proposed to give the menus page an accessibility option, like the widgets screen. At present, the screen to create new nav menus lacks an ability to turn off drag/drop functionality. That poses an accessibility problem when trying to order menu items. The widgets page solves that problem by giving the option to enable an accessibility mode, disabling drag/drop, and giving a user an easier option to position widgets according to a user’s preference. It is proposed that such functionality be incorporated in the creation/modification of nav menus if possible; Otherwise, such features are only partially accessible. WORDPRESS 3.6 ALPHA For WordPress 3.6 alpha, for MP6 plugins and the new user interface, there may be three areas of concern as follows: 1) the contrast on “Collapse Menu” may need to be increased, 2) low contrast ratios on post revision comparisons, 3) low contrast ratios on the text for inactive plugins on plugins pages, and 4)absolutely no way to “highlight” (increase the contrast) on the text without a mouse.
Received on Sunday, 28 April 2013 20:38:32 UTC