I'm reading a lot about reforming 1.5 to use standards-compliant xhtml, but nothing about adherance to W3C Web Content Accessibility Guidelines? Section 508 even? Is there any plans to try and reach at least Priority 1?
Sorry if I've missed a thread somewhere, I searched and didn't find much on the topic...
We are actually working on both XHTML and accessibility compliance at the same time. Have a look at test.moodle.com
On the test site, when you click on the section 508 check link at the bottom, why does it say:
Rule: 1.1.1 - All IMG elements are required to contain either the alt or the longdesc attribute.
- No IMG elements found in document body.
Rule: 1.1.2 - All INPUT elements are required to contain the alt attribute or use a LABEL.
- No INPUT Elements found within document
When there are cleary both input and img tags on the page?
If you go to the main page and enter any other moodle site you get a great deal more information
Fixed. The validator was temporarily redirecting from the main page due to some other changes.
excellent work 
glad to know about the test site, I'll keep an eye on it...
How is xhtml compliance going? The test site does not validate. How about v. 1.5dev?
Simon
I actually have no idea, but given that the validator only returns 3 trivial errors I'd have to deduce that xhtml compliance it going rather well!
When I last checked the front page of test.moodle.com had 31 html transitional errors.
Well it is called test.moodle.com because it is used to test features. I assume the RSS block and messaging service have been placed there in order to find the errors. (There's actually only 2 errors, unencoded ampersands in the RSS links account for most of the errors and a missing alt attribute text on a message image.)
Trying to search the forums still breaks in Firefox in a really bizarre way though.
Is there documentation anywhere of what's been done and what's planned vis a vis XHMTL compliance and accessability? It would probably be a better guage of progress than validating random pages.
Yeah, you're right about the errors. Sorry, I counted the total instances of the two errors. I've not been able to find any detailed info regarding progress of xhtml compliance .
Si
I'm sorry if I have missed threads with the answer to this question, but is 1.5 going to address 508 issues? We are running 1.4.3 now and preparing for an accreditation visit in March in which 508 compliance probably will come up. In testing our 1.4.3 site with Bobby and Cynthia Says, we ran into numerous alt-text problems with the various icons associated with course listings and labels on forms controls. We can probably hack a fix to get by but I'd rather not have to do this if something better is coming in 1.5.
thanks
dawn
You can test how Moodle 1.5 is doing by going to test.moodle.com, especially the "Miscellaneous things" course.
Gustav
Thanks. I just ran Cynthia Says on the test home page and the overall report is good except the image alt-tags problem is still there I think for the icons (guest, info, key, course? ) . These are a few lines (all are the same except for line3 and col #) of the report:
Warning - IMG Element found at Line: 126, Column: 1913 contains the 'alt' attribute with an empty value. Please verify that this image is only used for spacing or design and has no meaning. Warning - IMG Element found at Line: 126, Column: 2127 contains the 'alt' attribute with an empty value. Please verify that this image is only used for spacing or design and has no meaning. Warning - IMG Element found at Line: 128, Column: 308 contains the 'alt' attribute with an empty value. Please verify that this image is only used for spacing or design and has no meaning. Failure - IMG Element at Line: 128, Column: 680 Warning - IMG Element found at Line: 135, Column: 19 contains the 'alt' attribute with an empty value. Please verify that this image is only used for spacing or design and has no meaning. Warning - IMG Element found at Line: 136, Column: 128 contains the 'alt' attribute with an empty value. Please verify that this image is only used for spacing or design and has no meaning.
The icons are inside an <a> tag and both the <a> tag and the <img> tag have the title attribute set. Does this information really need to be repeated in the alt attribute of the icon? It seems to me that any screen reader or other accessibilty software should be able to use the title attribute.
Don't get me started on my "why don't people hassle the screen-reader makers instead of every webpage producer on the planet?" rant!
In any case, we are dutifully and robotically putting in the useless title tags that the standards suggest.
In any case, we are dutifully and robotically putting in the useless title tags that the standards suggest.
Yes, we are putting in all the title attributes, even where they are redundant. But as the above example shows that still doesn't please all accessibility checkers, they want the alt attributes set as well. Are we going to go along with that as well?
I'll chime in this discussion with a question.
What is easier, to add alt tags or to explain the very sophisticated reasons to everybody running the test and getting warnings? So I think, using descriptive title tags and short alt tags would help everybody and avoid those warnings.
I noticed, that firefox doesn'd show the alt description but only the title description - is that right?
Yes Urs, it's quite right. To understand exactly what's going on keep on reading. 
If there is text inside the anchor tag next to the image, and we use a non-empty alt attribute for the image, I believe that the resulting output from a screen reader or a text-based browser will actually be wrong.
You can see what I mean in Firefox. Locate an item such as I describe, then Tools -> Options -> Web Features and uncheck "Load Images".
So in these situations, we really should use an empty alt attribute.
If there is text inside the anchor tag next to the image, and we use a non-empty alt attribute for the image, I believe that the resulting output from a screen reader or a text-based browser will actually be wrong.
You can see what I mean in Firefox. Locate an item such as I describe, then Tools -> Options -> Web Features and uncheck "Load Images".
So in these situations, we really should use an empty alt attribute.
There's a couple of issues interacting here;
The
altandtitleare two different things, any browser that used one in the place of the other would be utterly braindead. Needless to say Internet Explorer does this, which has led to general confusion about their purpose. In brief: alt (short for alternative) is displayed when the image isn't, title expands upon the image/alt text and is generally displayed when you hover over the image. In depth: joe clark on accessible images (warning: that book chapter includes, for no obvious reason, a link to a site of an adult nature)It is not possible for a computer to check the accessibility of a webpage, just as it is impossible for a computer to check the spelling of your word processed document. Yes, it can underline Moodle in red because it's not in its list of words, but it will remain silent about using 'there' instead of 'their'. Similarly, accessibility checkers are usually explicit that they are only the first step in a process that requires human intervention.
In this particular example, the empty alt tags are actually the correct response since Moodle has many spacer gifs (it's been a while since I've needed to use that phrase!). Such images have no meaning and therefore should not show up in text/audio browsers. Lazy developers don't add any tags at all and so they show up as the filename by default (e.g. "spacer.gif") in text/audio browsers. Moodle developers have therefore actually put the effort in to add empty alt tags to improve the accessibility of the site. On the other hand, the icons for the info, guest access and enrolment key do all have appropriate alt texts already ("Summary", "This course allows guest users to enter" and "This course requires an enrolment key" respectively).
So Moodle gets a gold star for accessibility (in this case at least).
The failure by the way is a missing alt attribute for the slashdot logo in the RSS block.
Thanks, these explanations have been helpful. So every icon that has explanatory text next to it should have an empty alt tag and every icon that does not have explanatory text next to it should have a non-empty alt attribute. An example of the later is provided by those on course/index.php and course/category.php as seen by the admin. So someone needs to go through all empty alt attributes and check what kind of icon they are used in and fix them where necessary.
Gustav
I am not a programmer by trade, but I am pretty quick at catching on and know a bit about code. If you point me in the right direction, perhaps I can help track down icons with empty alt tags.
dawn
If you have downloaded the Firefox browser and its Web Developer Extension then you can select the following from the Images menu:
- Outline images with empty alt attributes
- Outline images without alt attributes
To see where there may be issues of text needing to be added to alt attributes.
There is also:
- replace images with alt attributes
Which will show up inappropriate use of alt text, usually needless duplication, that can be fixed by using empty alt attributes instead. I note that when I use this functionality in Moodle, e.g. on the forum entry page I'm currently using, the replacement text is often quite ambiguous
By the way, could someone approve my glossary addition of Web Developer Extension? I recommend it quite a lot and it's a chore to look up the info each time. Thanks!
Re. alt and title attributes, I found Titles and alternative text for images helpful in understanding the difference.
A big thank you to everyone working on improving accessibility in 1.5.
A big thank you to everyone working on improving accessibility in 1.5.
Thanks everyone for responding. I know that these accessibility checkers are not the final word but the problem is kind of like having a newspaper declare you are guilty on the front page and then you must work to prove you are innocent. A VP in our university who is not Moodle-friendly ran Bobby on our Moodle install and submitted the report to the senior committee preparing for the coming SACS review (SACS is our regional accreditation group). Now I have to rebut his claim that Moodle does not comply with 508.
If I understand the real situation, the main icons on the course listing are compliant but there are some spacer-gifs that are triggering the 508 warnings. I have run Bobby and Cynthia Says further "inside" Moodle, e.g. after a student logs in and enters a course, and so far get no 508 problems reported, although I have not run them on every screen in every mod. I am going to prepare a short report for the SACS committee summarizing this discussion and run it up the flagpole.
Again thanks for all the hard good work you are doing.
Just found this discussion - rather late unfortunately.
I'm running trough all the language files in alphabetical order, searching for errors and trying to convert them for XHTML compliance.
The XHTML-compliance situation in the language files is at this moment:
af ok
ar help ok / php not ok
be ok
bg ok
ca ok
cs ok
da ok
de ok
de_du okl
el help\ -> look for recent dates
en ok
eu ok
hu php ok
nl ok
sv ok
A few things are still wrong in the language packs wich are considered ok:
Another problem is keeping it that way. Despite the fact that this discussion and the guidelines for xhtml are anounced around october, there are still new files checked in wich are based on old English helpfiles or containing tags in capitals, unclosed <p> etc.
I'm running trough all the language files in alphabetical order, searching for errors and trying to convert them for XHTML compliance.
The XHTML-compliance situation in the language files is at this moment:
af ok
ar help ok / php not ok
be ok
bg ok
ca ok
cs ok
da ok
de ok
de_du okl
el help\ -> look for recent dates
en ok
eu ok
hu php ok
nl ok
sv ok
A few things are still wrong in the language packs wich are considered ok:
- closing / in img-tags
- alt should be replaced with alt=""
- cascaded use of <ul> or <ol> without <li> for indenting
- other things I've missed ???
Another problem is keeping it that way. Despite the fact that this discussion and the guidelines for xhtml are anounced around october, there are still new files checked in wich are based on old English helpfiles or containing tags in capitals, unclosed <p> etc.
I've been working my way through de-tabling all the forms and converting them over to a semantically correct layout (I'll post examples when I get one I'm happy with). Although the main advantage of this is for disabled users, there's also the 2 advantages to users of faster page loads and having labels that work (clicking focuses on the field).
The only problem so far is that I'm having trouble deciding where to put the help icons and error messages in a sematic sense...
<label> Your name: <input type="text" name="name" /></label>
I've stripped it down for simplicity but I'm sure you get the idea.
Scenario is that the user submits without filling in the field. So they get the page back with a helpful summary of all error messages
across the top of the page and each specific error message (or a marker) placed next to the bad field.
My question is: where should the 2nd error message go semantically?
<label> Your Name *error msg* : <input...></label>
<label> Your Name : <input.../>*error msg*</label>
<label> Your Name : <input.../></label>*error msg*
*error msg*<label> Your Name : <input...></label>
Or none of the above? Can the error be considered part of the label? Certainly it's specifically associated with the the field, but is it, strictly speaking, a label?
As an extension to this, what if you want to present
fieldname : [_________] (?)
where (?) is a help icon and link out to a glossary (for example). Is the help link part of the label?
I'm not sure there's a clear cut answer to this. I've not come across anyone addressing this before.
Gav
The only problem so far is that I'm having trouble deciding where to put the help icons and error messages in a sematic sense...
<label> Your name: <input type="text" name="name" /></label>
I've stripped it down for simplicity but I'm sure you get the idea.
Scenario is that the user submits without filling in the field. So they get the page back with a helpful summary of all error messages
across the top of the page and each specific error message (or a marker) placed next to the bad field.
My question is: where should the 2nd error message go semantically?
<label> Your Name *error msg* : <input...></label>
<label> Your Name : <input.../>*error msg*</label>
<label> Your Name : <input.../></label>*error msg*
*error msg*<label> Your Name : <input...></label>
Or none of the above? Can the error be considered part of the label? Certainly it's specifically associated with the the field, but is it, strictly speaking, a label?
As an extension to this, what if you want to present
fieldname : [_________] (?)
where (?) is a help icon and link out to a glossary (for example). Is the help link part of the label?
I'm not sure there's a clear cut answer to this. I've not come across anyone addressing this before.
Gav
I can't answer the question but I'm interested in the answer and looking forward to seeing an example in action!
One other thing to include is that tag to make TAB jump properly from field to field in the right order (can't remember what the tag is offhand).
One other thing to include is that tag to make TAB jump properly from field to field in the right order (can't remember what the tag is offhand).
tabindex. The other related problem to this is that, really, one should have access keys for key functions like [s] gives focus to the search box (for example).
Sure, but on pages where there's just one form, taborder would be nice. The user profile page, for example. There's a bug on this somewhere (rummage) .. bug #2650
I've put together my current thinking at
http://gmontague.co.uk/moodle/form_test.html
It's still quite hacky but I think it demonstrates the main points.
*MSIE 5 & 6, as always, refuse to play nicely. Although they to provide some support for labels I've had to nest a span inside them to provide a width for the actual label text. MSIE refuses to take the labels because of this. There is a way round it but it breaks backwards compatibility with older browsers. Is there a Moodle guideline, "must be compatible with browsers x through z"?
http://gmontague.co.uk/moodle/form_test.html
It's still quite hacky but I think it demonstrates the main points.
- Tableless design that degrades in a readable way
- Field labels that work in conforming browsers*
- Tabindex, as requested
- Removal of the inline javascripting with a dynamic event for supporting browsers
*MSIE 5 & 6, as always, refuse to play nicely. Although they to provide some support for labels I've had to nest a span inside them to provide a width for the actual label text. MSIE refuses to take the labels because of this. There is a way round it but it breaks backwards compatibility with older browsers. Is there a Moodle guideline, "must be compatible with browsers x through z"?
You could argue that the error message is part of the label that is being emphasised, so putting it inside the label, wrapping an em tag around it and then styling that appropriately might be the most semantic solution.
-Matt
-Matt
Hi,
I'm new to Moodle and a beginner at php and so am desperately trying to keep up . I don't know for sure about the error message but shouldn't the code for labels go like this...
<label for="bert"> Your Name *error msg* :</label> <input ... name="bert" id="bert" />
Although thinking about it I'd probably go for:
<label for="bert"> Your Name :</label> <input ... name="bert" id="bert" />*error msg*
Please correct me if I'm wrong or ignore me if I have the wrong end of the stick!
I also have a question - when is the accessible version of moodle due to be released?
There's two different ways to mark up labels for forms.
You can use the label for="id", or you can contain the relevant form section inside the label tag.
You can read more than you probably ever wanted to know about accessible forms in this book chapter
To answer your second question, I don't think there is an 'accessible version' as such. Moodle is already accessible for a wide range of users and continues to focus on improving its accessibility, as well as it's usability, security and pedagogic flexibility. None of these aims have obvious finish lines though each release is (hopefully) an improvement and so the next release (1.5) should be more accessible/secure etc.
That may seem like a cop-out but in my opinion it's the only truly honest answer, and you'd presumably get the same answer from any other website/service that is seeking to be accessible. I would be suspicious of anyone who claimed they were "accessible enough" and had no further room for improvement.
Of course if you have any specific problems with the accessibility (or security, usability or pedagogy) of Moodle then you can always discuss it in the forums, enter a bug report or make suggestions for improvement.
As already mentioned, there are two ways to specify a target for a label: the 'for' attribute or just by nesting the input within the label. Each is valid and has it's own advantages, but the main factor s in not using 'for' (at least, not exclusively) are more to do with browser mechanics.
1. MSIE doesn't support 'for'
2. IMHO, in a bog-standard form that takes the form left aligned labels and then a field next to it the whole area to the left of the input should be 'hot' (Fitt's law).
As for an accessible version of Moodle, I'm in the middle of re-writing the HEAD build as a tableless layout with full labels, alts, etc (about 30% done so far). The only problem is that it's very difficult to do a bit of it as a standalone for submission for the approval of the Moodle Guru's.
G
1. MSIE doesn't support 'for'
2. IMHO, in a bog-standard form that takes the form left aligned labels and then a field next to it the whole area to the left of the input should be 'hot' (Fitt's law).
As for an accessible version of Moodle, I'm in the middle of re-writing the HEAD build as a tableless layout with full labels, alts, etc (about 30% done so far). The only problem is that it's very difficult to do a bit of it as a standalone for submission for the approval of the Moodle Guru's.
G
Why not just tackle a page at a time? I'm not going to be able to do anything with a giant patch like that ... Are you not working on the forms anymore - that seemed like a promising start.
In any case, I've yet to be convinced that lean page layout tables are not accessible. In fact, many people with older or embedded browsers (or IE will find the inevitable broken mish-mash quite inaccessible. Just reading all the CSS hacks people need to go through to achieve really basic page layout on all browsers gives me a huge headache. I'd give it another year or two before trying for this unless you're really having fun experimenting with it.
In the meantime we should have templates anyway.
In any case, I've yet to be convinced that lean page layout tables are not accessible.
In the meantime we should have templates anyway.
The layout I'm using at the moment is pretty friendly back to NN4, beyond that I'm just degrading to styleless. In some ways I agree with you about having some structural tables, but from what I've read a lot of people (including the peeps who are financing me at the moment) need the "official stamp of accessablily" from uni/gov departments and that usually comes with a thou-shalt-not-use-tables clause.
As for submitting what I'm up to, I know I'll have to submit it a page at a time but I'm still getting to grips with the moodle codebase and I'll be much happier sending things in when I'm sure they're in keeping with the rest of the code. I'm still doing the forms: I expect I'll be emailing you some bits of the quiz mod by the end of next week if time allows. I'm currently in multitasking hell
G
As for submitting what I'm up to, I know I'll have to submit it a page at a time but I'm still getting to grips with the moodle codebase and I'll be much happier sending things in when I'm sure they're in keeping with the rest of the code. I'm still doing the forms: I expect I'll be emailing you some bits of the quiz mod by the end of next week if time allows. I'm currently in multitasking hell
G
Hi Vicki, 1.5 is aiming to be Sec 508 compliant, you can help us get there by joining test.moodle.com, and then post bug reports for pages that don't meet section 508 guidelines.
Yes, sorry, my question was badly worded. How about a more simple
"do you have a vague idea when version 1.5 will be ready?"
(or is that the sort of question that makes developers have to go off and sit quietly in darkened rooms?) 
We need a VLE that complies with SENDA and in the 'future' section of my Moodle Documentation it says Version 1.5 will be around 'Later in 2004' and also that it will make Moodle 'fully compliant' with important web accessibility standards such as WAI (W3C), SENDA (UK)' as well as Section 508.
Please don't get me wrong, I'm not complaining! I just need to know a general ball-park date (ie late 2005). I know it depends on many many different things and people and that I should be jolly well helping out rather than just sitting here asking annoying questions
As for the label info - thank you, there's my thing learnt for today!
I have joined the test.moodle and will have a delve.
Ahh, I finally found the little crevice where 'accessibility' was being discussed here! Thank goodness for forum searches!!
My name is Michael Roush, and I am the technology consultant for a place called Hopewell SERRC... a state-funded special education center in Ohio, USA. I also conduct workshops on accessible web design at regional and state tech conferences. We are seriously considering using Moodle for online course management. I'm not sure which US Federal guidelines we fall under as far as accessibility of web-based content goes, but we have decided as an organization to make sure that all of our pages meet WAI Priority 2 standards, plus as many P3 standards as we can manage after that. In testing with some of the disabled people we serve, we found that Priority 1 compliance helped some, but not nearly as much as going further to P2, and it wouldn't take that much extra work.
This is part of my strong leaning toward using Moodle. I will be able to edit anything thhat I find that doesn't meet Priority 2 (and even some Priority 3) specs and thereby be able to include Moodle in our overall site plan and not break our commitment to providing accessible content to the people we serve.
My basic reason for coming here and posting is.... is there an individual or group that I should be talking to as far as what is being planned as far as accessibility for v1.5, and if there is any support I can lend to the effort?
My name is Michael Roush, and I am the technology consultant for a place called Hopewell SERRC... a state-funded special education center in Ohio, USA. I also conduct workshops on accessible web design at regional and state tech conferences. We are seriously considering using Moodle for online course management. I'm not sure which US Federal guidelines we fall under as far as accessibility of web-based content goes, but we have decided as an organization to make sure that all of our pages meet WAI Priority 2 standards, plus as many P3 standards as we can manage after that. In testing with some of the disabled people we serve, we found that Priority 1 compliance helped some, but not nearly as much as going further to P2, and it wouldn't take that much extra work.
This is part of my strong leaning toward using Moodle. I will be able to edit anything thhat I find that doesn't meet Priority 2 (and even some Priority 3) specs and thereby be able to include Moodle in our overall site plan and not break our commitment to providing accessible content to the people we serve.
My basic reason for coming here and posting is.... is there an individual or group that I should be talking to as far as what is being planned as far as accessibility for v1.5, and if there is any support I can lend to the effort?
Hi, Michael. No there's not a wealth of discussion in the forums but a lot of effort has been going into it.
What I need is for you (and anyone else) to please download the very latest Moodle 1.5 development version (I would recommend the CVS method so you can update daily) then bang on it and file specific bug reports for each accessibility problem in our bug tracker. Your help right now with this would be very much appreciated as we slide towards a beta release.
What I need is for you (and anyone else) to please download the very latest Moodle 1.5 development version (I would recommend the CVS method so you can update daily) then bang on it and file specific bug reports for each accessibility problem in our bug tracker. Your help right now with this would be very much appreciated as we slide towards a beta release.
I'm downloading it right now, and I added the bug tracker to my bookmarks. I routinely use a couple different web browsers, plus I keep some assistive tech tools handy on my system, so I will try to test what I do using what I have and report what I find!
I probably should have asked this in the very beginning when the call went out to snoop through the cvs for accessibility problems, but better late than never.
What level of conformance are you aiming for? WCAG-A, -AA, -AAA? A combination of national standards? I was planning to sort my findings out by WCAG checkpoint, and I could include cross-reference to US Sec508 regs. I'm not familiar enough yet with the text of Canada's "Common Look and Feel" or UK's DDA to offer direct correlation to their statements. Some statement regarding the level of conformance would be most helpful to folks who are interested in such things (whether by personal conviction or legal mandate), more so than just saying "It's accessible".
I won't question your choice, I just want to make sure the findings I submit go towards what you truly want to change, and maybe save you some of the trouble of weeding through the issues to determine which ones are important for the project.
What level of conformance are you aiming for? WCAG-A, -AA, -AAA? A combination of national standards? I was planning to sort my findings out by WCAG checkpoint, and I could include cross-reference to US Sec508 regs. I'm not familiar enough yet with the text of Canada's "Common Look and Feel" or UK's DDA to offer direct correlation to their statements. Some statement regarding the level of conformance would be most helpful to folks who are interested in such things (whether by personal conviction or legal mandate), more so than just saying "It's accessible".
I won't question your choice, I just want to make sure the findings I submit go towards what you truly want to change, and maybe save you some of the trouble of weeding through the issues to determine which ones are important for the project.
We've been mostly testing with Sec508 until recently, just because that was the default that "Cynthia Says" uses. There have been so many basic things to fix (with XHTML mostly) that I haven't even considered the various levels yet. I guess we aim for the simplest first (WCAG 1) and go from there.
In your site, when you are admin, you'll see links in the footer of every page (you must be using "standard" or "standardwhite" theme). I've just added it to standardwhite so that might take a while to come through to anonymous CVS. I also added a second Cynthia link that verifies WCAG 1 (with warnings for 2 and 3).
To make these links work properly and allow these services into your site, create a user on your site with the username "w3cvalidator". You can make this user a teacher, an admin, whatever you like.
When you click on a link and tell Cynthia where to come it'll be automatically logged in as this user and see the page you were on as you do.
In your site, when you are admin, you'll see links in the footer of every page (you must be using "standard" or "standardwhite" theme). I've just added it to standardwhite so that might take a while to come through to anonymous CVS. I also added a second Cynthia link that verifies WCAG 1 (with warnings for 2 and 3).
To make these links work properly and allow these services into your site, create a user on your site with the username "w3cvalidator". You can make this user a teacher, an admin, whatever you like.
When you click on a link and tell Cynthia where to come it'll be automatically logged in as this user and see the page you were on as you do.
In reply to Martin Dougiamas
Re: Accessibility: accessibility level in 1.5
yes i agree...sometimes a good documentation especially being on-line can help immensly...keep up the good work...thanks...indy ;+)