I'm working on a patch for a couple of tag-related bugs today. But before I started, I thought I would make sure I fully understood how the current edit screens worked. Specifically, the tag and category sections on the full Edit Post screen (as opposed to the Quick Edit screen).
Just to see what would happen, I turned of JavaScript in my browser. I was shocked: - You cannot see what tags are already on the post, if you edit an existing post. - If you type in a tag where it says "add a new tag", the "add" button does nothing, and if you then save the post, the tags you typed don't get added. - All of which means that there is no way, with JS disabled, to see or modify the tags on the post in any way, as far as I can tell. - Also, the "most recent" tab of the Categories section doesn't show when you click the tab, with JavaScript disabled. That's fairly minor, because you do have a list of all the categories available. - The Upload/Insert media section is totally gone without JavaScript.
So my question to the list is: Is the back end of WP supposed to work with JavaScript disabled? In other words, is this lack of functionality without JavaScript a bug, or was it done on purpose? I thought that standard web practice was to have things degrade nicely without JavaScript. I also thought that maybe some visually disabled users couldn't use JS-enabled browsers, but maybe that notion is hopelessly out of date? I also believe that in the past, the WP back end would work without JavaScript, but if you cannot do tags and media, I wouldn't say it works now. I'm not sure how long it's been like that...
Any insight appreciated.... It will affect what I do for this patch I'm working on, obviously.
Thanks, Jennifer
-- Jennifer Hodgdon * Poplar ProductivityWare www.poplarware.com Drupal, WordPress, and custom Web programming
There are two guidelines for accessibility -- two sets of standards: 1) WCAG - international W3C guidelines - requires functionality and content of web pages to be accessible if JS is disabled. 2) Section 508 - (US law) - requires that if JS is used, it is accessible to assistive technologies, and that the web page not require the use of a specific input device such as a mouse (so all content and functionality needs to be accessible using a keyboard without resorting to the mouse).
Neither of those guidelines works at all with the Edit Post page in the WP back end. Try using the tab key to navigate around the page sometime -- quite illuminating! You definitely cannot get to all of the functionality, it's in some random order, and there is no visual cue (such as a:active CSS) to show you what link you are over when you're on the left sidebar. With JS turned off, as I mentioned in my previous note, you can't do Tags or Media at all.
So what are WP's official Accessibility standards for the back end, if any?
--Jennifer
-- Jennifer Hodgdon * Poplar ProductivityWare www.poplarware.com Drupal, WordPress, and custom Web programming
On Fri, May 1, 2009 at 10:08 AM, Jennifer Hodgdon <yah...@poplarware.com> wrote: > So my question to the list is: Is the back end of WP supposed to work with > JavaScript disabled? In other words, is this lack of functionality without > JavaScript a bug, or was it done on purpose? I thought that standard web practice was to have things degrade nicely without JavaScript.
I would say if WordPress requires JavaScript to accomplish a certain task, then it's a bug.
* The WP requirements page says nothing about having a JavaScript-enabled client [1]. * From the first paragraph, the WP features page trumpets its W3C standards-compliance [2]. By failing to gracefully degrade in older clients, WP violates the W3C "Web Content Accessibility Guidelines" [3]. * WP hurts its potential market share by excluding those who must follow accessibility guidelines for their site.
Well, I would agree with you on all counts. The WP back end is clearly in violation of the WCAG... But what should we do about it?
The first thing to do would probably be WP Powers that Be to commit to making WP's back end WCAG compatible, or at least to agree that if it isn't, it's a serious bug. The next step would be to identify the actual WCAG violations, which would probably require an expert on accessibility (rather than someone like me making guesses) doing an assessment.
Then of course, to fix the issues, which we can all participate in and is probably doable. For instance, the separate "Media" page allows you to upload a file and edit the caption, etc., all without use of JavaScript (it's klunky and you cannot attach it to a post, but as a proof of concept, it's there).
Austin Matzko wrote: > I would say if WordPress requires JavaScript to accomplish a certain > task, then it's a bug.
> * The WP requirements page says nothing about having a > JavaScript-enabled client [1]. > * From the first paragraph, the WP features page trumpets its W3C > standards-compliance [2]. By failing to gracefully degrade in older > clients, WP violates the W3C "Web Content Accessibility Guidelines" > [3]. > * WP hurts its potential market share by excluding those who must > follow accessibility guidelines for their site.
On Fri, May 1, 2009 at 9:11 AM, Jennifer Hodgdon <yah...@poplarware.com> wrote: > The first thing to do would probably be WP Powers that Be to commit to > making WP's back end WCAG compatible, or at least to agree that if it isn't, > it's a serious bug.
FWIW we have a blind author on our site and he does fine with WP and his screen reader. I'm sure there are some readers that can't handle it as well but his success implies that WP is at least good enough that someone can work it out.
Interesting fact: he *prefers* tinymce. Apparently it's more accessible to his screen reader than the code view. (I know a lot of people like it these days, but that still seems counter-intuitive to me :P )
That is good to know. Jeremy: I have read that some of the dynamic update things could be difficult for (blind) screen reader users. How does your blind author like the Tags section, when he adds a tag and it appears? Can he use the X buttons to delete the tags?
* They may not be able to see, hear, move, or may not be able to process some types of information easily or at all. * They may have difficulty reading or comprehending text. * They may not have or be able to use a keyboard or mouse. * They may have a text-only screen, a small screen, or a slow Internet connection. * They may not speak or understand fluently the language in which the document is written. * They may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a loud environment, etc.). * They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system.
Jeremy Clarke wrote: > FWIW we have a blind author on our site and he does fine with WP and > his screen reader. I'm sure there are some readers that can't handle > it as well but his success implies that WP is at least good enough > that someone can work it out.
> Interesting fact: he *prefers* tinymce. Apparently it's more > accessible to his screen reader than the code view. (I know a lot of > people like it these days, but that still seems counter-intuitive to > me :P )
-- Jennifer Hodgdon * Poplar ProductivityWare www.poplarware.com Drupal, WordPress, and custom Web programming
On Fri, May 1, 2009 at 2:26 PM, Jennifer Hodgdon <yah...@poplarware.com> wrote: > That is good to know. Jeremy: I have read that some of the dynamic update > things could be difficult for (blind) screen reader users. How does your > blind author like the Tags section, when he adds a tag and it appears? Can > he use the X buttons to delete the tags?
Actually we don't use tags and I have the tags UI completely hidden through CSS because the users were tagging things anyway and filling up the DB, so I can't speak to that, given its newness it could be a point of failure.
> FWIW we have a blind author on our site and he does fine with WP and > his screen reader. I'm sure there are some readers that can't handle > it as well but his success implies that WP is at least good enough > that someone can work it out.
> Interesting fact: he *prefers* tinymce. Apparently it's more > accessible to his screen reader than the code view. (I know a lot of > people like it these days, but that still seems counter-intuitive to > me :P )
Could your blind user set up and manage his own WP though? Prior to WordPress 2.7, disabled users who use assistive devices were able to install & run their own sites. <2.7 was not accessible, but was more accessible than 2.7+.
During the survey on the new 2.7 UI this was mentioned by several people and was loudly shouted down by those who loved the look of the UI. It was also raised on wp-testers. It's not just the JavaScript/AJAX that makes the UI unusable by many though (this also catches those people behind corporate firewalls that block JavaScript) as the whole admin interface falls way short of meeting WCAG.
> It's not just the JavaScript/AJAX that makes the UI > unusable by many though (this also catches those people behind > corporate > firewalls that block JavaScript) as the whole admin interface falls > way > short of meeting WCAG.
Can you explain how a firewall can block a client technology?
> 2009/5/2 Jeremy Clarke <j...@simianuprising.com>
>> FWIW we have a blind author on our site and he does fine with WP and >> his screen reader. I'm sure there are some readers that can't handle >> it as well but his success implies that WP is at least good enough >> that someone can work it out.
>> Interesting fact: he *prefers* tinymce. Apparently it's more >> accessible to his screen reader than the code view. (I know a lot of >> people like it these days, but that still seems counter-intuitive to >> me :P )
> Could your blind user set up and manage his own WP though? Prior to > WordPress 2.7, disabled users who use assistive devices were able to > install > & run their own sites. <2.7 was not accessible, but was more > accessible than > 2.7+.
> During the survey on the new 2.7 UI this was mentioned by several > people and > was loudly shouted down by those who loved the look of the UI. It > was also > raised on wp-testers. It's not just the JavaScript/AJAX that makes > the UI > unusable by many though (this also catches those people behind > corporate > firewalls that block JavaScript) as the whole admin interface falls > way > short of meeting WCAG.
On Fri, May 1, 2009 at 8:32 AM, Jennifer Hodgdon <yah...@poplarware.com> wrote: > There are two guidelines for accessibility -- two sets of standards: > 1) WCAG - international W3C guidelines - requires functionality and > content of web pages to be accessible if JS is disabled. > 2) Section 508 - (US law) - requires that if JS is used, it is accessible > to assistive technologies, and that the web page not require the use of a > specific input device such as a mouse (so all content and functionality > needs to be accessible using a keyboard without resorting to the mouse).
> ...
> So what are WP's official Accessibility standards for the back end, if any?
A lot of work goes into meeting those (getting the new widgets admin to work without JS was no fun), but we're still way short. Patches and specific recommendations welcome. For example, I'd love someone to help with #9445 because I've added enough labels and fieldsets for a lifetime. http://core.trac.wordpress.org/ticket/9445 _______________________________________________ wp-hackers mailing list wp-hack...@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-hackers
> It's not just the JavaScript/AJAX that makes the UI >> unusable by many though (this also catches those people behind corporate >> firewalls that block JavaScript) as the whole admin interface falls way >> short of meeting WCAG.
> Can you explain how a firewall can block a client technology?
> +1 for accessibility though.
Yep, sure can. This is becoming increasingly common in corporate environments and I've recently been seeing it in school/university environments. Firewalls and proxy servers are getting configured to strip out JavaScript before the pages get sent to the client machine. So, even though the client browser may have JavaScript enabled, the script has already been removed and is unable to be accessed.
This is not a new problem. It's also not just an issue for JavaScript as some firewalls and proxies are over-cautious with their settings and block far more scripting than they need to. However, it becomes really problematic for WordPress where js is used for core functionality and not just for progressive enhancement.
Just a note - in both the tracker and comments made here, people seem to be focusing more on S.508 compliance. That is all well and good, but misses the fact that S.508 is a US government guideline, which is an amendment to the US Workforce Rehabilitation Act, 1973. Section 508 does not apply to private sector web sites or to public sites which are not U.S. Federal agency sites.
S.508 covers *some* of the requirements for an accessible SITE, but if we are looking at WordPress accessibility the guidelines we should be looking at are the Authoring Tool Accessibility Guidelines: http://www.w3.org/TR/ATAG10/
ATAG provides the information needed for WordPress to be an accessible authoring tool. WordPress itself cannot make a site accessible - that is up to a combination of both the theme and the user, as long as the underlying code meets the ATAG guidelines.
Making the back end of WordPress accessible is something I'd certainly be interested in helping with, and I know a few other people that would be as well.
I've looked at the page referenced to from trac http://www.wac.ohio-state.edu/tutorials/forms/hiding-labels.htm and that page is out of date - I'm sure Jaws now honours display:none for a start. Moving labels off screen via the 'off-left' technique appears to be the best solution.
You also have to be aware that a lot of screen readers have a 'form' mode. In which they won't read anything out except for form tags - legends labels etc. So any additional text should not appear within the form unless associated with form markup. But adding in labels is only a portion of what needs doing, I'd be arguing that the scope= in tables is not the best solution and that headers and ids should be used (but I'll admit to not being upto dat on what screenreaders can cope with best). I'd also be suggesting that using tables to layout forms isn't good...
IF Automattic decide they want the back end to be accessible, firstly all javascript should be turned off, and the interface tested to be working. Then add the javascript back in as an enhancement - that alone will help. (and yes I know these days that some of the screen readers can cope with javascript).
On Sat, May 2, 2009 at 1:26 AM, Rich Pedley <elf...@googlemail.com> wrote: > Making the back end of WordPress accessible is something I'd certainly > be interested in helping with, and I know a few other people that > would be as well.
> I've looked at the page referenced to from trac > http://www.wac.ohio-state.edu/tutorials/forms/hiding-labels.htm > and that page is out of date - I'm sure Jaws now honours display:none > for a start. Moving labels off screen via the 'off-left' technique > appears to be the best solution.
We had several people running JAWS against 2.7 before release and all was well. Alas, I don't have it to test with. Could someone who actually uses it let us know how it's handling labels. Ignoring hidden labels would seem to make little sense. They exist solely for the benefit screen readers.
Eric Marden wrote: > Can you explain how a firewall can block a client technology?
Many firewalls have the capability to do that. You can just block any HTTP requests that end with '.js', for one thing, or block responses with a Content-type of text/javascript or application/javascript (and other techniques). But organizations that want to do that will more likely have their users running thin clients or lock down the desktop OS security settings so that javascript is disabled in the browser, block the users from changing the settings.
> On Sat, May 2, 2009 at 1:26 AM, Rich Pedley <elf...@googlemail.com> wrote: > > Making the back end of WordPress accessible is something I'd certainly > > be interested in helping with, and I know a few other people that > > would be as well.
> > I've looked at the page referenced to from trac > > http://www.wac.ohio-state.edu/tutorials/forms/hiding-labels.htm > > and that page is out of date - I'm sure Jaws now honours display:none > > for a start. Moving labels off screen via the 'off-left' technique > > appears to be the best solution.
> We had several people running JAWS against 2.7 before release and all > was well. Alas, I don't have it to test with. Could someone who > actually uses it let us know how it's handling labels. Ignoring > hidden labels would seem to make little sense. They exist solely for > the benefit screen readers.
JAWS has honoured the "display:none" for several years now, making anything hidden by "display:none" hidden from JAWS as well. It also honours "visibility:hidden".
> That is good to know. Jeremy: I have read that some of the dynamic update > things could be difficult for (blind) screen reader users. How does your > blind author like the Tags section, when he adds a tag and it appears? Can > he use the X buttons to delete the tags?
Note: WCAG 2.0 is the current version. It can be found here: http://www.w3.org/TR/WCAG20/ It contains some significant changes from WCAG 1.0 and also addresses some issues where WCAG 1.0 was not worded correctly (which meant it was being misinterpreted).
> We had several people running JAWS against 2.7 before release and all > was well. Alas, I don't have it to test with. Could someone who > actually uses it let us know how it's handling labels. Ignoring > hidden labels would seem to make little sense. They exist solely for > the benefit screen readers.
yes but display:none has been used for other things, not just labels.
Whilst on the subject of accessibility, it should be noted that by default WP produces some things which can be considered inaccessible. One prime example is the 'Read more' link text. In WCAG 1 it stated that link text should be unique. the Read More link specifically can appear several times on a page, but link to different pages. I know it can be customised, but if you want WP to be considered accessible out of the box, then that would need changing. ( I can't say for certainty what appear in WCAG 2, I'm not fully upto speed with it).
I don't know how accurate it is, but there is a Firefox plugin called "Fangs" that is designed to take a page and turn it into text approximating what a user of JAWS hears.
2009/5/4 Stephen Rider <wp-hack...@striderweb.com>
> FYI --
> I don't know how accurate it is, but there is a Firefox plugin called > "Fangs" that is designed to take a page and turn it into text approximating > what a user of JAWS hears.
Fangs is useful as a very basic, unsophisticated reading tool but does not emulate JAWS or EYES. It is however useful for getting an idea of how a page reads. Fire Vox is another Firefox addon - this does a better job but, again, does not emulate JAWS. Both Fangs and Fire Vox are useful aids to theme designers and site owners who do not have much experience with accessibility but who want to get an indication as to how accessible their sites may be.
Its also worth noting that even though you can download a trial of JAWS this is not likely to help determine the level of accessibility. JAWS (and EYES) are really complicated to use and, JAWS especially, takes a lot of time and training to learn. Then to add to the mix, the results from testing with JAWS are further influenced by which browser is being used to access the web, and the level of experience the user has with both JAWS and the browser. Add to this the fact that people use different versions of assistive devices and different versions of browsers, and the whole testing thing becomes very complex.
However, this is why W3C has its web accessibility initiative (WAI) and if WordPress can meet ATAG in the administration area, and WCAG 2 requirements in the frontend, it will achieve a high level of accessibility (and beat competing blogging platforms hands down).
|
