Also posting in the General Developer Forum.
The Open University (UK) is starting to contribute to the development
of Moodle. We have requirements for accessibility to students and
teachers with disabilities, so we have a proposal to modify Moodle with the help of you core developers.
The attached document explains our proposal, who we think could do
what, and which files and parts of Moodle will be affected. The work is
scheduled for the next 3-4 weeks. Please let us know your views.
Nick-I'll just comment on a few points you make
- Suggest users are encouraged to provide a brief description of their image to convey the same message as the image, and include this as alt text for the image.
- The purpose of the description field is not clear. If it is for user to provide a description of themselves, suggest description of me or similar.
- Tables are used for layout. Suggest: investigate use of CSS for some if not all layout (it is acknowledged that this is not a perfect science).
Hi Nicole, thank you for your comments - very useful.
User profile - user image 'Alt' text: at present there is an empty 'Alt' attribute for the 2 cases when the user supplies a photograph or not, so this is unacceptable from an accessibility perspective. The suggestion was after a brief look by someone new to Moodle, and I agree that at least part of the alt text needs to be automated. Also, a description from the user would require a change to the database schema, so I suggest "User photo, none supplied" and "User photo for NN" would fit the 2 cases - after all there is no guarantee that the image shows the user (it may be their cat!)
Tables for layout v. CSS - a contentious issue! First, layout tables cause a problem for screen reader users who hear confusing and unnecessary "table, row, row, table..." from their software, for those using screen magnification software and for those using a small-screen - anyone who doesn't conform to the designer's wishes. Usable web design moves away from absolute 'control' of the user view to a flexible design that varies with screen width and user requirements.
I have been looking at this in detail, and the aim initially will be to remove deeply nested tables that are redundant - they no longer contribute to the layout. When significant tables are replaced with CSS we will test with a wide variety of browsers and screen sizes so that overlapping and unreadable text does not occur. Most modern browsers have reasonable support for CSS 2 and if an old, buggy browser is in use the implication is that the user is not concerned with pixel-perfect graphics. In this case the design will 'degrade gracefully' so that for instance instead of navigation and content blocks appearing next to each other, one will appear below the other - the text will still be readable.
I hope this answers your concerns - do respond. Thanks, Nick.
User profile - user image 'Alt' text: at present there is an empty 'Alt' attribute for the 2 cases when the user supplies a photograph or not, so this is unacceptable from an accessibility perspective. The suggestion was after a brief look by someone new to Moodle, and I agree that at least part of the alt text needs to be automated. Also, a description from the user would require a change to the database schema, so I suggest "User photo, none supplied" and "User photo for NN" would fit the 2 cases - after all there is no guarantee that the image shows the user (it may be their cat!)
Tables for layout v. CSS - a contentious issue! First, layout tables cause a problem for screen reader users who hear confusing and unnecessary "table, row, row, table..." from their software, for those using screen magnification software and for those using a small-screen - anyone who doesn't conform to the designer's wishes. Usable web design moves away from absolute 'control' of the user view to a flexible design that varies with screen width and user requirements.
I have been looking at this in detail, and the aim initially will be to remove deeply nested tables that are redundant - they no longer contribute to the layout. When significant tables are replaced with CSS we will test with a wide variety of browsers and screen sizes so that overlapping and unreadable text does not occur. Most modern browsers have reasonable support for CSS 2 and if an old, buggy browser is in use the implication is that the user is not concerned with pixel-perfect graphics. In this case the design will 'degrade gracefully' so that for instance instead of navigation and content blocks appearing next to each other, one will appear below the other - the text will still be readable.
I hope this answers your concerns - do respond. Thanks, Nick.
Currently the 'alt' text for the user's image is exactly right. Please don't change it.
Remember 'alt' stands for alternative. It is meant to convey equivalent information to the image for people who cannot, or choose not, to see the image.
So what information does the user's image convey. I can think of:
1) In forum posts etc., it gives an added visual cue as to who made each post, but conveys exactly the same info as the user's name which is printed beside it.
2) In the user profile, it lets you see what someone looks like, if you are interested.
So in summary, it conveys approcimatly zero useful information. Therefore the correct alt tag is "", which is what it is already. If you really want people who can't see your photo to know what you look like, then type it into the description field, which is already there.
The best rule of thumb I have come across for working out the right alt text is to imaging that you are reading out the web page to someone over the phone. So you are reading the text on the page, and you come to an image. What, if anything, would you bother saying in place of the image?
Tim.
Remember 'alt' stands for alternative. It is meant to convey equivalent information to the image for people who cannot, or choose not, to see the image.
So what information does the user's image convey. I can think of:
1) In forum posts etc., it gives an added visual cue as to who made each post, but conveys exactly the same info as the user's name which is printed beside it.
2) In the user profile, it lets you see what someone looks like, if you are interested.
So in summary, it conveys approcimatly zero useful information. Therefore the correct alt tag is "", which is what it is already. If you really want people who can't see your photo to know what you look like, then type it into the description field, which is already there.
The best rule of thumb I have come across for working out the right alt text is to imaging that you are reading out the web page to someone over the phone. So you are reading the text on the page, and you come to an image. What, if anything, would you bother saying in place of the image?
Tim.
I second Tim's recommendation that a blank alt attribute (which is different from a 'missing' alt attribute) is the most suitable choice for the user photo. This fits with advice I've had many times from accessibility professionals, with roughly the logic that Tim describes. If you (Nick) have information that suggests otherwise, I'm certainly open to new information, but that's what I've heard and believed for a while.
That's a minor issue though. I'm very happy that you're proposing to do such work. The general outline looks good.
Please don't eliminate all tables, of course! One 'grey area' I'm thinking about is config forms. Moodle uses tables to lay out the configuration options on all the setup pages, and it's not clear to me whether your proposals would count these as 'layout' or 'data' tables. I appreciate the issues involved but there has never been a good CSS alternative to this specific kind of layout job, which aligns form elements and their descriptions in a meaningful way. However, the HTML <label> element, and good use of TH tags rather than TD tags where appropriate, should be able to remedy this. Moodle does not currently do too well at this: there are many cases where the <label for="blah"> technique should be used to make sure that a text-field is correctly connected with its label (for example), but this hasn't been used.
I would say that the point about the asterisk next to the profile link (indicating that the profile is not fully completed) is lower than a "medium" priority - after all, the asterisk is just a gentle hint, not an indication of anything that has a bearing on the learning experience or the operation of the system.
That's a minor issue though. I'm very happy that you're proposing to do such work. The general outline looks good.
Please don't eliminate all tables, of course! One 'grey area' I'm thinking about is config forms. Moodle uses tables to lay out the configuration options on all the setup pages, and it's not clear to me whether your proposals would count these as 'layout' or 'data' tables. I appreciate the issues involved but there has never been a good CSS alternative to this specific kind of layout job, which aligns form elements and their descriptions in a meaningful way. However, the HTML <label> element, and good use of TH tags rather than TD tags where appropriate, should be able to remedy this. Moodle does not currently do too well at this: there are many cases where the <label for="blah"> technique should be used to make sure that a text-field is correctly connected with its label (for example), but this hasn't been used.
I would say that the point about the asterisk next to the profile link (indicating that the profile is not fully completed) is lower than a "medium" priority - after all, the asterisk is just a gentle hint, not an indication of anything that has a bearing on the learning experience or the operation of the system.
Setting your form layout with a table is not really a grey area. You shouldn't be using tables for purely onscreen layout benefit, and forms are just another example of this.
That it's harder to produce a CSS-based form across a range of browsers is certainly true, but there are a fair few articles on the subject and it's gotchas - Jeff Howden's page is a nice starting point. You can get simple form layouts (like most of Moodle's) to work as far back as IE5 with minimal tweaking. If you're clever you can avoid too much div-itis.
That it's harder to produce a CSS-based form across a range of browsers is certainly true, but there are a fair few articles on the subject and it's gotchas - Jeff Howden's page is a nice starting point. You can get simple form layouts (like most of Moodle's) to work as far back as IE5 with minimal tweaking. If you're clever you can avoid too much div-itis.
I have to disagree. There is a case for having empty 'Alt' text when an image duplicates or adds no extra information an icon for a link which also has text. However, empty or no 'Alt' text implies that you are deciding what you think the non-visual user wants, and this is my least-preferred option. I think many users would want a hint as to what the image contains this is not an incidental image.
In this case it may even be useful a non-visual user may want to upload a photo for others, and the phrase "User photo, none supplied" would remind them whether they already one.
In this case it may even be useful a non-visual user may want to upload a photo for others, and the phrase "User photo, none supplied" would remind them whether they already one.
Previous post should be dated, 28 February 16:28 GMT!
I've had further discussions with my colleagues and I'm changing my view slightly. From my experience of using Screen readers, I appreciate the amount of information - much of it not important - that the user has to absorb. A modification that adds unnecessarily to the information should not made - in the case of the user image next to each post in a forum thread I agree that the 'Alt' text should be left blank.
Generally, I'll be looking carefully at each case, and where I judge that 'Alt' text is required, using the minimum number of words.
I've had further discussions with my colleagues and I'm changing my view slightly. From my experience of using Screen readers, I appreciate the amount of information - much of it not important - that the user has to absorb. A modification that adds unnecessarily to the information should not made - in the case of the user image next to each post in a forum thread I agree that the 'Alt' text should be left blank.
Generally, I'll be looking carefully at each case, and where I judge that 'Alt' text is required, using the minimum number of words.
I agree with Tim and Dan that an empty alt tag is probably appropriate for user images that are situated right next to the users name, as I believe it generally acts as a visual signature or identifier.
I would note that there are areas (well at least one, but I'll have to check exact locations) where a user image on its own is hyperlinked to the user profile. I would suggest that adding the name to those would be a (minor) accessibility improvement.
I would note that there are areas (well at least one, but I'll have to check exact locations) where a user image on its own is hyperlinked to the user profile. I would suggest that adding the name to those would be a (minor) accessibility improvement.
To follow up my previous point.
The list of choice responses is one area where the image is linked, when perhaps both the icon and name should be contained within the A tag.
There is also the 'more detailed' view of Participants, again with the image not the name linked to the profile, though in this case there is also a (small, and not very obvious) 'full profile' link.
The list of choice responses is one area where the image is linked, when perhaps both the icon and name should be contained within the A tag.
There is also the 'more detailed' view of Participants, again with the image not the name linked to the profile, though in this case there is also a (small, and not very obvious) 'full profile' link.
Hi, Nick!
Sorry about the delay ... things have been a little crazy here catching up from a long trip overseas.
The report in general is great, and yes it would be good to have those smaller non-controversial things (like headings etc) going straight into HEAD, cheers.
Others have shown that some of the changes that seem obvious (alt tags) in fact need more careful thought (and have already received some careful thought in the past).
I would mostly caution strongly that we are heading towards a beta in few weeks at most, so please don't do anything that would delay that further.
Especially, big things like removing layout tables on pages like the main course page is of concern to me. I want to do it, but it needs to be done in a way that retains the stretchy nature of the current layout, with all the proper flow in the center column, and no wierd CSS overlapping that one often sees. And this should work in all common browsers.
I know it's possible, but it will need a lot of testing etc so I need to be convinced it's fairly stable already before it goes into HEAD. Perhaps these could be done as new course formats for a while to help testing.
I'm 100% for helping the disadvantaged but let's not disadvantage the rest of us when we do it.
Sorry about the delay ... things have been a little crazy here catching up from a long trip overseas.
The report in general is great, and yes it would be good to have those smaller non-controversial things (like headings etc) going straight into HEAD, cheers.
Others have shown that some of the changes that seem obvious (alt tags) in fact need more careful thought (and have already received some careful thought in the past).
I would mostly caution strongly that we are heading towards a beta in few weeks at most, so please don't do anything that would delay that further.
Especially, big things like removing layout tables on pages like the main course page is of concern to me. I want to do it, but it needs to be done in a way that retains the stretchy nature of the current layout, with all the proper flow in the center column, and no wierd CSS overlapping that one often sees. And this should work in all common browsers.
I know it's possible, but it will need a lot of testing etc so I need to be convinced it's fairly stable already before it goes into HEAD. Perhaps these could be done as new course formats for a while to help testing.
I'm 100% for helping the disadvantaged but let's not disadvantage the rest of us when we do it.
A very big caution is that if anything you are doing will break Moodle 1.5 themes then you need to
a) Try and avoid that
b) Document it fully for us so that Theme designers have a checklist for upgrading their themes.
a) Try and avoid that
b) Document it fully for us so that Theme designers have a checklist for upgrading their themes.
Hi Martin
I've used your suggestion to create an evaluation 'weekscss' course format. The target is to maintain current 3-column graphical view using relative widths for pixel screen sizes 800x600, 1024x768... on IE6, Firefox. Below 800 pixels columns will start to shift downwards.
So far I've replaced <table>, <td> with DIVs. The next step will be to reorder the columns so that in a linear view the content appears before both block columns - watch this space.
References, Ideal line length for content, max-width in Internet Explorer .
I've used your suggestion to create an evaluation 'weekscss' course format. The target is to maintain current 3-column graphical view using relative widths for pixel screen sizes 800x600, 1024x768... on IE6, Firefox. Below 800 pixels columns will start to shift downwards.
So far I've replaced <table>, <td> with DIVs. The next step will be to reorder the columns so that in a linear view the content appears before both block columns - watch this space.
References, Ideal line length for content, max-width in Internet Explorer .
Some interesting reading, very good stuff!
I have some minor comments and questions (and one rather larger issue, which probably deserves its own post):
Having left hand and right hand menus may be difficult for screenreaders because they come both before and after the main content of the page. This requires further consideration as to how to make it useful for sighted and blind users alike. P3 (but perhaps should be higher)
In the short term, I believe adding an empty table cell at the top of the two side columns will cause the central column to be read first (followed by the left then right column) in systems that linearize tables. This is certainly a hack (I'm sure I read it somewhere reputable but can't find a link at the moment), but if it works with the accessibility software tested then it might be worth doing. Obviously if a move to CSS positioning is made then the position in the HTML is effectively decoupled from the visual presentation.
Text size cannot be changed via browser menu without setting browser to ignore font sizes first. This makes it difficult for many users who cannot easily read 12pt text. Suggest font size is not fixed in stylesheet, but is relative.
Is this true? I thought the only problem was with Internet Explorer and sites that specified fonts in pixels. I just tried increasing the font size on Moodle.org with IE on XP sp2 and it worked fine, all I had to do was choose View > Text Size > Large (or Largest)
» in breadcrumb trail is read by screenreader as greater than greater than or double right angle bracket.
Is there any particular reasoning for the alternative symbols suggested? I noticed that > ('greater than') wasn't listed, which a) is the standard usage in my experience, b) is logical in the sense that the list is a heirarchy, and c) gets recommended as part of Yahoo's Web User Interface Patterns Library
Abbreviations Mon, Tue, Wed etc may not be meaningful to all screenreader users, but difficult to offer solution that does not take up space
How do screenreaders react to ABBR or ACRONYM tags? I've read that they're patchy or semi-useless for accessibility in some way, but I've never clearly had it explained why.
Fixing the » character is easy, it's done in one function. In fact it replaces "->" which is what the modules actually insert from the old days. 
One day we really need to be passing an array of items to that function rather than a string.
Personally I think all the other options are a bit daggy-looking by comparison to the right-angle quote. What do the exalted screenreader manufacturers recommend?
Probably there should be a variable set in the themes/*/config.php to let the theme designer to specify a bit of HTML to go in there.
One day we really need to be passing an array of items to that function rather than a string. Personally I think all the other options are a bit daggy-looking by comparison to the right-angle quote. What do the exalted screenreader manufacturers recommend?
Probably there should be a variable set in the themes/*/config.php to let the theme designer to specify a bit of HTML to go in there.
My big question with regard to accessibility is about the HTML editor. It gets mentioned in the report, but only from the angle of using the editor itself. I've always been concerned about the accessibility of the output. Not just in terms of the code produced, but in the general mindset that it promotes.
For example I'm amazed at the number of times I've seen text like this used for emphasis. I get confused by that, never mind new web users. So the kind of issues are (incomplete and off the top of my head):
(As an aside, I was going to say I was pleased to see that it works with the Google spellcheck so I wouldn't have to continually ignore 'Moodle' as an allegedly mispelled word, but it actually got a bit fankled at the end, and wouldn't stop spellchecking, obviously a javascript clash.)
I *can* see the benefits of a WYSIWYG editor (to a certain extent) especially the associated javascript image placement stuff, and I know there are some available that transparently rewrite the underlying HTML to be clean and somewhat semantic. I've also seen that the HTML editor is configurable, and I assume that it could be tailored or streamlined in some way to be more semantic (e.g. choosing 'monospaced' rather than a particular monospaced font, not allowing random text size/color changes, banning underlining).
So I guess my questions are: does anyone else care? Is this a genuine accessibility issue? Is everyone else just uploading Word .docs, .pdfs, and .ppts rather than creating content in Moodle? I'm surprised that this has never really been discussed or seen as an issue. We (University of Glasgow) currently have a policy of turning the editor off completely. This is not ideal (for sharing documentation/screenshots/tutorials via e.g the docs wiki) and I'd be overjoyed if there was a movement to clear up this issue so that we could re-enter the fold of mainstream Moodlers, but on the other hand, with my current experience I can't honestly recommend the HTML editor be used as it currently stands.
I would welcome any and all thoughts or opinions on this.
For example I'm amazed at the number of times I've seen text like this used for emphasis. I get confused by that, never mind new web users. So the kind of issues are (incomplete and off the top of my head):
- it lets you set the font, from a specific list. If my phone or linux box doesn't have these fonts (or my eyesight isn't good enough to distinguish), and they are being used to convey information, e.g. text in this font is commentary not the core text, then information is being lost.
- issues surround the choice of colour, with not everyone being aware of the impact of color choices and contrast on the color blind and other low vision users.
- you can set levels of heading, but you can also 'fake' the same by changing the boldness and text size
- the previous three items probably fall under the general heading of non-semantic markup and styling that would be completely lost on a speech reader, as well as the specific problems I mentioned.
- part of me is horrified by the uglyness of every poster and editor getting to choose their own font (and size, color etc.) and I can even rationalise it that across a site consistency would help readability and usability of information.
- Many other issues, generally each minor when considered on it's own, where people are encouraged to believe that because it looks fine on their machine, to them, it will be fine for others with different platforms and abilities.
(As an aside, I was going to say I was pleased to see that it works with the Google spellcheck so I wouldn't have to continually ignore 'Moodle' as an allegedly mispelled word, but it actually got a bit fankled at the end, and wouldn't stop spellchecking, obviously a javascript clash.)
I *can* see the benefits of a WYSIWYG editor (to a certain extent) especially the associated javascript image placement stuff, and I know there are some available that transparently rewrite the underlying HTML to be clean and somewhat semantic. I've also seen that the HTML editor is configurable, and I assume that it could be tailored or streamlined in some way to be more semantic (e.g. choosing 'monospaced' rather than a particular monospaced font, not allowing random text size/color changes, banning underlining).
So I guess my questions are: does anyone else care? Is this a genuine accessibility issue? Is everyone else just uploading Word .docs, .pdfs, and .ppts rather than creating content in Moodle? I'm surprised that this has never really been discussed or seen as an issue. We (University of Glasgow) currently have a policy of turning the editor off completely. This is not ideal (for sharing documentation/screenshots/tutorials via e.g the docs wiki) and I'd be overjoyed if there was a movement to clear up this issue so that we could re-enter the fold of mainstream Moodlers, but on the other hand, with my current experience I can't honestly recommend the HTML editor be used as it currently stands.
I would welcome any and all thoughts or opinions on this.
Hi David.
Thanks for taking the time to contribute. Yes, we have concerns both over the user-interface for the editor and the semantics of the output it produces. The htmlArea editor is third party and is integrated into Moodle at present. It contains complicated code and is going to be replaced, see Forums » HTML editor » time to change the WYSIWYG editor? See, tinyMCE on Sourceforge.
I don't know the timescale, so I'll report again on our plans when I know more.
Thanks for taking the time to contribute. Yes, we have concerns both over the user-interface for the editor and the semantics of the output it produces. The htmlArea editor is third party and is integrated into Moodle at present. It contains complicated code and is going to be replaced, see Forums » HTML editor » time to change the WYSIWYG editor? See, tinyMCE on Sourceforge.
I don't know the timescale, so I'll report again on our plans when I know more.
Janne, the guy in charge of the editor implementation in Moodle, has been working hard on adding TinyMCE to Moodle already, hopefully for 1.6.
He has added a user preference so that each user can choose which one they want to use.
He has added a user preference so that each user can choose which one they want to use.
My choice was the compromise of disabling the font /size/color and a few other editor options in our moodle instance, to try and avoid too much un-semantic markup flooding it. We also try to educate staff as much as possible with a styleguide that encouraged real heading use, links that are meaningful out of context and so on. Of course this doesn't deal with the span-itis of the editor or styles coming from uncleaned pasted Word-documents, so it's a temporary fix at best. I'll be interested to see how good the markup from the new editor is.
One option we've also been using is CourseGenie, as it plugs into Word and aids you with producing vaguely accessible web pages/ SCORMs. However this is an addon rather than something internal to Moodle, and there's a certain confusion that has to be overcome when you use one tool and add it to another.
However, many tutors go straight to uploading documents, it's easy for making their information available right away (they have these materials already). This produces a whole raft of problems for users, as downloads aren't handled consistently cross browser, not all formats are backward compatible, people don't have the software and so on. An option in Moodle to upload a Word document and auto-covert/clean it to a web resource (similar to writely) might fit better with the task flow that tutors seem to follow naturally.
One option we've also been using is CourseGenie, as it plugs into Word and aids you with producing vaguely accessible web pages/ SCORMs. However this is an addon rather than something internal to Moodle, and there's a certain confusion that has to be overcome when you use one tool and add it to another.
However, many tutors go straight to uploading documents, it's easy for making their information available right away (they have these materials already). This produces a whole raft of problems for users, as downloads aren't handled consistently cross browser, not all formats are backward compatible, people don't have the software and so on. An option in Moodle to upload a Word document and auto-covert/clean it to a web resource (similar to writely) might fit better with the task flow that tutors seem to follow naturally.
Hi Nick and everybody,
You use the acronym TBC in your paper - what does it mean?
Apologies, I have to think of the international audience! TBC - to be confirmed.
- Headings
because the headings and a semantic page structure are important for non visual navigation we need a good concept for the use of headings in the Moodle pages. Additionally there should be recommendations for the use of headings in the content area.
If the Moodle pages use H1 - H3 for the semantic page structure, H4 - H6 can be used for the content.
What do you think about collecting examples of well structured web pages?
One example I noticed is: http://ma.gnolia.com/.
I'd have a concern about a logic that puts the content's priority lower that the general page elements, as the heading levels imply a heirarchy.
As to examples, anything from Zeldman is a good bet (go via alistapart) or work by other members of the web standards project (particularly the Accessibility Task Force)
Similar to headings, making lists of things (like currently logged-on users) actual list elements, is also a great help.
One simple thing that's a big advantage (for both screenreaders and anybody using a small-screen device) is providing the ability to skip repetitive navigation and straight to the content.
As to examples, anything from Zeldman is a good bet (go via alistapart) or work by other members of the web standards project (particularly the Accessibility Task Force)
Similar to headings, making lists of things (like currently logged-on users) actual list elements, is also a great help.
One simple thing that's a big advantage (for both screenreaders and anybody using a small-screen device) is providing the ability to skip repetitive navigation and straight to the content.
Seeing the whole page content is embeded into the page and comes behind header and overall page structure.
Content is most important when you read, but not for the page structure.
But content is the primary structure of a page. In fact, don't think of it as a page, think of it as a document. Which bits of it are most important?
I'm not saying that structure blocks are irrelevant, but they shouldn't be made more relevant than the core content. That's what the page is there to deliver, after all.
I'm not saying that structure blocks are irrelevant, but they shouldn't be made more relevant than the core content. That's what the page is there to deliver, after all.
This is an interview with Derek Featherstone in Digital Web Magazine about his accessibility work http://www.digital-web.com/articles/derek_featherstone/
It is quite interesting and some of the topics of the Moodle Accessibility Proposal are covered.
- tables for layout
it will be great when you can reduce the tables used for layout.
With the necessary knowledge you can build websites completely without tables. But you need to care for content in those websites. If you can not care for the content, especially length of words and the use of <pre> tags, table less layouts will lead to overlapping text in some areas.
Therefore Moodle will need a mixture of many relative and absolute positioned divs and some few tables keeping content together. I suggest building the pages with divs. And then for example use for the critical area of the course page one 3 column layout-table for the content.
With Martin's proposal to evaluate different approaches of table less course pages with course formats will be a great way to enhance Moodle pages to using as few as possible layout tables.
After I read about the Layoutgala I tried to let content come first in the page structure by positioning the content area in a three column layout before the two sideblock areas. This works perfectly. To keep the content in the columns I put 3 tables into the column divs. But when content is added for example to the sideblocks and this content is wider than the column width the columns jump to a different place on the page. This is even more disgusting than overlapping text.
What are your plans how to proceed? Will you show us your plans how to change the pages before you start or will you start working and let us follow the changes in the CVS?
- font-size
As David mentioned above I also do not understand your topic about text size. I just checked the standard CSS files and all font-sizes are defined with "em". This is a relative measurement and all browsers change the text size by user commands. Could you please explain where you saw fixed font sizes in the stylesheets?
I know that there are some areas in Moodle code where font tags are still used. They surely should be replaced by proper XHTML and CSS.
Thank you very much.
- breadcrumb trail
Several postings mentioned that the use of unordered lists will be a good solution for accessibility tasks. They are good solutions for visual styling tasks too.
The breadcrumb trail should be build with an unordered list. One example on Listomatic shows how to style those lists without any separator in the content. The separator can be added via CSS and can be a picture or text. There are many more examples for different styling. And the site offers a browser compatibility chart.
David mentioned the Yahoo Pattern Library which is a good way to describe things. I started to collect some basic stuff which could/should be used with all Moodle pages. The one and only topic is the use of unordered lists in Moodle.
The page name "Standards" is a bit misleading. Better is to call it "Moodle Design Patterns". The "Moodle Design Patterns" will help documenting changes and offer a base for all Moodle developers to use the same patterns for there modules or sideblocks. In this work on Moodle accessibility with all it's code and CSS changes I see a valuable starting point for "Moodle Design Patterns". What do you think?
- left hand menus
Nick, your proposal to replace the table structure of the sideblocks with lists is great. David Scotson worked out an example for lists in sideblocks: CSS Blocks. David, could your work be a good starting point for Nick?
Hi Urs. Thanks for your many contributions - I'm working through them I've already reworked sideblocks to use lists, see weblib.php: function print_side_block in HEAD. I'm looking at David Scotson's contribution to see if there is anything I've missed.
Generally, search for 'Accessibility:' in comments to find PHP code I've changed.
Generally, search for 'Accessibility:' in comments to find PHP code I've changed.
My main concern with the change to lists in the sideblocks is the semantics and naming. I strongly believe that good names must be chosen for classes, much like good variable names. Not that compilers or web browsers care, but other programmers/web developers do.
So seeing a ul (that is, an unordered list) with a class of list strikes me to be as confusing as an Integer called int, which may be fine if your writing mathmatical code where it really is just an integer but in most cases it will be a count or a total. In this case perhaps sideblockmenu would be more appropriate.
Similarly, the use of r1 and r0 never made much sense to me when used to markup tables, (I would have much prefered class 'odd' with 'even' being entirely optional, since 'even equals not odd') and there was in fact places in the tabs HTML that got r0 and r1 understandably confused (and may still be actually, I've not checked recently) which meant you had to have duplicate CSS for the same kind of tabs on seperate pages. So carrying this on to mark up list items, when the variable means row0/1 seems to invite double confusion.
Finally, using c0 and c1, which I believe stands for cell 0 and cell 1, to refer to spans is somewhat confusing. In addition, the icon could be put into the css as a background-image, which would allow zoom or high contrast themes to change both the image and its size (or postion, filetype etc.) with much greater ease than if it's hardcoded into the HTML.
Overall, I think it would be a shame if the effort to further accessify Moodle takes a narrow focus of replacing table cells with spans, rather than converting to more semantic code which would actually have a positive impact on far more users' experience of Moodle (whether they consider themselves to be in need of accessible software or not). I know the semantic code is more effort, and causes even more disruption, but I worry that once the automated accessibility checkers are satisfied and the 'accessible' tickbox has been ticked that real users will be left somewhat disadvantaged, with no external motivation to move things forward.
I agree that class names like 'list', r0, c0 and so on, don't tell developers much. The initial concern was to have a close mapping from tables or cells to <div>, <span>, <ul> and to not break style sheets.
I think its an improvement semantically to have a <ul> with legacy class-name 'list' in place of <table class="list">! The enclosing <div> has useful class names, for example "block_site_main_menu", "sideblock".
And yes, I would like to implement the icons using background-image or list-style, but the $icons array contained <img> elements so I made the first step a small one. Remember, at this stage in the 1.6 development we want low risk changes.
I am working towards accessibility and usability guidelines for Moodle developers, but at present layout tables are one of the big issues. Search for '//Accessibility:' to see the less visible changes that have happened.
I think its an improvement semantically to have a <ul> with legacy class-name 'list' in place of <table class="list">! The enclosing <div> has useful class names, for example "block_site_main_menu", "sideblock".
And yes, I would like to implement the icons using background-image or list-style, but the $icons array contained <img> elements so I made the first step a small one. Remember, at this stage in the 1.6 development we want low risk changes.
I am working towards accessibility and usability guidelines for Moodle developers, but at present layout tables are one of the big issues. Search for '//Accessibility:' to see the less visible changes that have happened.
Sustainability of your work.
It is my considered opinion that these changes to make Moodle accessible must be communicated to all developers. And that they must be the base for all future development. From the accessibility point of view following these guidelines will not be optional any more - it is a must to ensure accessibility in the future. Any part of Moodle not being accessible will break the whole experience.
Written styleguides like the Design Pattern approach with examples can help a lot to keep the right direction. Developers can build on proven knowledge without the need to try and test their code for accessibility and style again and again.
I see developers being much more responsible not only to make their code work and secure but also to make it a working part of an overall accessibility and design framework. Martin I remember some plans to establish one person in the Moodle headquarters with the task to coordinate development. How are these plans proceeding?
> Martin I remember some plans to establish one person in the Moodle
headquarters with the task to coordinate development. How are these
plans proceeding?
Goodness me it's what we do every day.
I would really like to finish this page one day, though.
http://docs.moodle.org/en/Interface_guidelines
Perhaps after 1.6 release I'll get some time.
Goodness me it's what we do every day.
I would really like to finish this page one day, though.
http://docs.moodle.org/en/Interface_guidelines
Perhaps after 1.6 release I'll get some time.
@Goodness me it's what we do every day.
I know that you do a great job with coordinating what I want to call the "core developer circle". All other people somehow involved in the Moodle development process with for example some modules, blocks, themes or simmilar do not know about the plans, new features etc.
I am sure that somebody actively looking at all those projects and proactively getting in contact with people to encourage them to use the Moodle API, the Moodle design patterns, the central libs etc. will make Moodle even better than it is now. It will be better because all parts will better work together.
The good work Helen does with Moodel Docs is a great example. She is very activly making contacts and is getting people involved. (Helen, thank you very much for your great engagement and invaluable work for Moodle.)
Martin, what do you think about my proposal to build a repository about Moodle design patterns like for example Yahoo offers. (See my proposal in this thread)
Urs
I read this article "IBM hopes open-source API will help speech recognition".
Can speech recognition also be part of making Moodle more accessible?
Hi Urs. Sorry for the delay in replying - busy, busy.
I have experimented with XHTML+Voice using the Opera browser - the IBM speech recogniser/synthesiser can be plugged in to it. A number of elements added to each page can make them voice-enabled, but the use of additional XML namespaces can break validation, and there may be a visual impact. A plug-in which modified the page header or footer would be appropriate.
I agree with your concerns regarding the sustainability of accessibility work. I have some ideas about guidelines and the Moodlemoot would be good place to get developers on board.
Cheers, Nick
I have experimented with XHTML+Voice using the Opera browser - the IBM speech recogniser/synthesiser can be plugged in to it. A number of elements added to each page can make them voice-enabled, but the use of additional XML namespaces can break validation, and there may be a visual impact. A plug-in which modified the page header or footer would be appropriate.
I agree with your concerns regarding the sustainability of accessibility work. I have some ideas about guidelines and the Moodlemoot would be good place to get developers on board.
Cheers, Nick
Hi Nick,
Came across your changes in 1.6 dev with a bit of a shock. Have a couple of questions re: theme development from now on.
Firstly. I also wish to point out that I belive making Moodle more acessible is brilliant and well overdue. My concern is making sure impacts are minimised for a 1.6 roll out.
As I launched my updated 1.6 dev this morning, My block headings when nuts and the breadcrumbs turned into a menu list.
Investigation led me to your changes and I had to rebuild my CSS to match.
Will someone be rebuilding existing moodle standard themes to match your requirements for the 1.6 launch?
If done..will these themes now be backwards compatible? The incluse of <i> and <h2> tags really changes how the themes will have to set out how these elements will sit.
Julian
Came across your changes in 1.6 dev with a bit of a shock. Have a couple of questions re: theme development from now on.
Firstly. I also wish to point out that I belive making Moodle more acessible is brilliant and well overdue. My concern is making sure impacts are minimised for a 1.6 roll out.
As I launched my updated 1.6 dev this morning, My block headings when nuts and the breadcrumbs turned into a menu list.
Investigation led me to your changes and I had to rebuild my CSS to match.
Will someone be rebuilding existing moodle standard themes to match your requirements for the 1.6 launch?
If done..will these themes now be backwards compatible? The incluse of <i> and <h2> tags really changes how the themes will have to set out how these elements will sit.
Julian
Nick, this is really important.
Firstly, these changes WILL break thousands of existing custom themes. I really hope the breadcrumbs-as-list was worth it. All themes in the distribution MUST be updated before 1.6, at least those themes who have built on top of these will have a chance of working. I know Moodle Partners will be dreading this upgrade.
Secondly, why the <i>You are here</i> using italics and not a span?
Thirdly, the new arrow images are hardcoded to the pix directory and should use $CFG->pixpath so that themes can insert their own. They could also have less cryptic and shorter names to shave a few bytes (navarrow.gif ? next.gif?).
We need a really clear and detailed 1.6 THEME UPGRADE CHECKLIST in Moodle Docs for theme designers to follow. Perhaps Urs could start one for Nick to add notes to.
Firstly, these changes WILL break thousands of existing custom themes. I really hope the breadcrumbs-as-list was worth it. All themes in the distribution MUST be updated before 1.6, at least those themes who have built on top of these will have a chance of working. I know Moodle Partners will be dreading this upgrade.
Secondly, why the <i>You are here</i> using italics and not a span?
Thirdly, the new arrow images are hardcoded to the pix directory and should use $CFG->pixpath so that themes can insert their own. They could also have less cryptic and shorter names to shave a few bytes (navarrow.gif ? next.gif?).
We need a really clear and detailed 1.6 THEME UPGRADE CHECKLIST in Moodle Docs for theme designers to follow. Perhaps Urs could start one for Nick to add notes to.
I added a section about the image borders, I added some code to do this a while back and don't think anyone but Urs responded to my call for opinions.
Anyone else used it, liked it, loathed it, even noticed it?
Crucially, it doesn't really draw attention to itself until you upgrade from a previous version. I think the code managed to escape into the Moodle.org branch and caused a minor uproar, but has since gone very quiet, it would be good to avoid surprising people again, since I'll feel responsible.
Anyone else used it, liked it, loathed it, even noticed it?
Crucially, it doesn't really draw attention to itself until you upgrade from a previous version. I think the code managed to escape into the Moodle.org branch and caused a minor uproar, but has since gone very quiet, it would be good to avoid surprising people again, since I'll feel responsible.
Hi Martin. Sorry to have got you concerned - I perhaps haven't been communicating my changes and there likely impact clearly enough. I will also post to the themes forum.
I think you can see from Urs' comments that the themes issue is not as big as you initially feared. I have now used Moodle's theme previewer to quantify the impact - a quick and dirty table is attached which demonstrates that of the 15 themes previewed 12 appear to need no change - 80% success. The 3 that need some modification include the 'pda' theme, which would have need checking for accessibility/usability in any case.
Why the <i>You are here</i> using italics...?
- I like compact markup, but in this case I agree it could confuse other developers - will fix ASAP.
New arrow images... should use $CFG->pixpath
- will fix ASAP, and look at filenames. (The 'em1' in the name refers to them being resizable - try Ctrl + Mouse wheel.)
I'm fully aware of the need to minimise risk at this late stage and I will work with the theme maintainers. I hope this reassures you - comments welcome.
Thanks Nick
I think you can see from Urs' comments that the themes issue is not as big as you initially feared. I have now used Moodle's theme previewer to quantify the impact - a quick and dirty table is attached which demonstrates that of the 15 themes previewed 12 appear to need no change - 80% success. The 3 that need some modification include the 'pda' theme, which would have need checking for accessibility/usability in any case.
Why the <i>You are here</i> using italics...?
- I like compact markup, but in this case I agree it could confuse other developers - will fix ASAP.
New arrow images... should use $CFG->pixpath
- will fix ASAP, and look at filenames. (The 'em1' in the name refers to them being resizable - try Ctrl + Mouse wheel.)
I'm fully aware of the need to minimise risk at this late stage and I will work with the theme maintainers. I hope this reassures you - comments welcome.
Thanks Nick
Yes, our theme inheritance model does mitigate a lot of the possible damage but I still see a lot of private themes that don't use this feature properly. We just need good documentation and examples that we can point to in the release notes.
But I'm cool to go ahead, like I said, just as long as those downstream are kept in mind.
And lastly but not least, even if seem like an old worrywart sometimes I do really like to see the improving accessibility! Thanks for all the effort, we'll get there!
P.S. the graphics don't resize for me in Firefox ...
But I'm cool to go ahead, like I said, just as long as those downstream are kept in mind.
And lastly but not least, even if seem like an old worrywart sometimes I do really like to see the improving accessibility! Thanks for all the effort, we'll get there!
P.S. the graphics don't resize for me in Firefox ...
I know I am simply using a version of standard that I modified on my Moodle. Didn't bother to try and figure out what needed to be done to get it to work properly on its own when I upgraded to 1.5 but since I haven't upgraded since it wasn't a problem. It would be a problem with 1.6 unless I figure out how to get it working. So clear and easy to understand instructions on how to use a custom theme alongside standard are necessary as Martin says.
Martin
"...the graphics don't resize for me in Firefox".
Thanks, I have fixed the resizing bug for the » image in the breadcrumb. The other images: < > on the calendar block, and > on the search forum block, resize fine for me.
Let me know if there is still a problem. Also, I have to work on the quality of the images < > in the calendar block.
Nick
"...the graphics don't resize for me in Firefox".
Thanks, I have fixed the resizing bug for the » image in the breadcrumb. The other images: < > on the calendar block, and > on the search forum block, resize fine for me.
Let me know if there is still a problem. Also, I have to work on the quality of the images < > in the calendar block.
Nick
Hi Nick
FYI, the breadcrumb graphics are out of whack for me in IE and Firefox using Formal White on the latest 1.6 version (updated last night via CVS - 2006032200).
Regards
H
FYI, the breadcrumb graphics are out of whack for me in IE and Firefox using Formal White on the latest 1.6 version (updated last night via CVS - 2006032200).
Regards
H
Hi all
Has Formal White been looked at for issues with 1.6 yet?
Due to the changes for accesibility the breadcrumb image ( >>) is messing with the layout as can be seen above. Just upgraded to 1.6 Beta via cvs and still the same.
Not knowing about these things, not sure whether it's a theme issue or coding issue, the new breadcrumb image is supposed to resize but doesn't appear to with Formal White.
Regards
H
Has Formal White been looked at for issues with 1.6 yet?
Due to the changes for accesibility the breadcrumb image ( >>) is messing with the layout as can be seen above. Just upgraded to 1.6 Beta via cvs and still the same.
Not knowing about these things, not sure whether it's a theme issue or coding issue, the new breadcrumb image is supposed to resize but doesn't appear to with Formal White.
Regards
H
Martin, great idea to document the process in Moodle Docs and not in documents attached to forum posts.
Please go to the Moodle Docs 1.6 theme upgrade page to read about the changes.
Nick, I started to write about some changes. Moodle Docs gives us the chance of collaborative work on the change documentation. Do you mind to continue to document your work there?
I added files to give everybody interested an overview of the changes in the header, footer and the CSS files from 1.5 to 1.6. When you open the linked files you will see all changes made in that file. You can add these changes to your theme header, footer and CSS files to update them for Moodle 1.6.
I will update these files with the differences regularly (every day when possible) until Moodle 1.6 will be released.
Urs
Hi Julian. The problems you encountered with themes when updating Moodle are unfortunate - I hope you've fixed things OK.
After your experiences, I've looked at the impact of my changes on the themes shipped with Moodle - see the reply to Martin. I have been careful to make backwards-compatible adjustments to code, and style sheets in the standard theme, so though there are issues to resolve, most themes look right - the standard theme is there in the background.
The use of <i> elements was a mistake, and will change. H2 for block and main content headings, and unordered-lists for breadcrumb and block navigation add semantics, useful for everyone, but especially non-visual users.
I hope these answer your points - I welcome your comments.
Yours, Nick
After your experiences, I've looked at the impact of my changes on the themes shipped with Moodle - see the reply to Martin. I have been careful to make backwards-compatible adjustments to code, and style sheets in the standard theme, so though there are issues to resolve, most themes look right - the standard theme is there in the background.
The use of <i> elements was a mistake, and will change. H2 for block and main content headings, and unordered-lists for breadcrumb and block navigation add semantics, useful for everyone, but especially non-visual users.
I hope these answer your points - I welcome your comments.
Yours, Nick
Hi Nick.
Thankyou for your response. I must admit I had a pretty severe knee jerk reation to the changes as they were unexpected. Howevere, like most here, I welcome the changes with open arms. Elearning for the disabled is of huge interest. And thus, making moodle more accessable to those with disabilities should also be a key area of work and ongoing discussion.
I suppose my issues boiled down to a lack of information being distributed regarding said changes. I have built numerous custom themes for many clients and was worried about the impacts of changes. And the only way to find out your changes had been to bury myself in weblib.php and the standard theme looking for your comments.
So, in short. I would be much happier if you could put all your changes into MoodleDocs and then inform, through a post on the themes forum, theme developers of these changes so that we can ensure that the 1.6 upgrade is not a hellish experience.
Julian
Thankyou for your response. I must admit I had a pretty severe knee jerk reation to the changes as they were unexpected. Howevere, like most here, I welcome the changes with open arms. Elearning for the disabled is of huge interest. And thus, making moodle more accessable to those with disabilities should also be a key area of work and ongoing discussion.
I suppose my issues boiled down to a lack of information being distributed regarding said changes. I have built numerous custom themes for many clients and was worried about the impacts of changes. And the only way to find out your changes had been to bury myself in weblib.php and the standard theme looking for your comments.
So, in short. I would be much happier if you could put all your changes into MoodleDocs and then inform, through a post on the themes forum, theme developers of these changes so that we can ensure that the 1.6 upgrade is not a hellish experience.
Julian
Hi,
this is an interesting and very important discussion.
Yesterday I sent Nick an e-mail which I will post here. It documents another view on the points mentioned by Julian and Martin:
--- email start ---
Hi Nick,
thank you for your really great work on your Moodle accessibility project. I try my themes every once in a while to follow the process of the page breaking apart. Nothing ugly happened so far Great.
Your work on changing the header and the sideblocks is great. And a special thank for making the "breadcrumb" a list!
One point I want to mention. For the CSS files we should use the smallest amount of code possible. When setting a property to "0" CSS does not expect any measurement. I saw that you added "%" to "0" and I know that you find developer dependent "px" "em" etc. What do you think about deleting all those measurements in the standard CSS files? If you agree could you please remove them where you find them?
How are you proceeding with your process to eliminate the tables?
Regards,
Urs
--- email end ---
Martin, with Nicks work on making Moodle accessible we see a prove of concept for our way to build themes. We can surly be a bit proud about our decision. I am . When theme designers build their themes using the "styles_layout.css" from the standard theme and add their own CSS files the pages wont break in Moodle 1.6.
I do not notice heavy faults with themes built this way (documented in Moodle Docs ). Julian reports major problems with his playpen site. He decided to rebuild all CSS files and not to base on "styles_layout.css".
@"breadcrumb"
Martin, yesterday I noticed the "breadcrumb" changes because the entries in the list where displayed beneath each other. After the update from today the "breadcrumb" looks as expected again. So I see no more problem with it. Do you?
Nick surly will have to double check that all themes build the "standard way" continue working without breaking the page. Some changes will be necessary and are ok in the Moodle enhancement process.
Urs
Nick, I am very happy to hear that you have plans for publishing developer guidelines. No need to wait for the MoodleMoot (at which I will not be able to participate ). You can start a page at MoodleDocs now! I like Urs's page on changes to the standard theme.
Hi Nick and all.
Marvin Hunkin here.
a web design and web admin student from Burnie Campus tasamia, online, via Devonport Campus.
using windows 2000 pro, novell client 4.9 and jaws for windows 6.1
i use moodle at our campus and the address is http://www.tafeitbur.com.au
now in your proposal any chance of making the standard chat module, and the chat more accessable with jaws, and to put in moodle at the moment.
my lecturer, possibly may put in a-tutor and a-chat, but not have heard yet, and when i try to type in the chat window, in forms mode on, jumps out and says cannot find the window, or cannot find the link , and keeps refreshing, thus confusing jaws.
and the same when i login, and see people on the main tafe moodle it site, and click on messages, the screen refreshes every 60 seconds, and jaws struggles to read the messages.
any chance of these problems being fixed and done asap, or yesterday if possible.
let me know either on the forum or e- me privately.
cheers Marvin.mail
Marvin Hunkin here.
a web design and web admin student from Burnie Campus tasamia, online, via Devonport Campus.
using windows 2000 pro, novell client 4.9 and jaws for windows 6.1
i use moodle at our campus and the address is http://www.tafeitbur.com.au
now in your proposal any chance of making the standard chat module, and the chat more accessable with jaws, and to put in moodle at the moment.
my lecturer, possibly may put in a-tutor and a-chat, but not have heard yet, and when i try to type in the chat window, in forms mode on, jumps out and says cannot find the window, or cannot find the link , and keeps refreshing, thus confusing jaws.
and the same when i login, and see people on the main tafe moodle it site, and click on messages, the screen refreshes every 60 seconds, and jaws struggles to read the messages.
any chance of these problems being fixed and done asap, or yesterday if possible.
let me know either on the forum or e- me privately.
cheers Marvin.mail
Hi Marvin
Sorry I didn't get back sooner. As mentioned in the proposal attachment, we are initially concentrating on what we (the Open University) need immediately, which does not include chat. It is something that we or the Moodle development team will look at after the 1.6 release.
Your experience and suggestions will be useful when we come to do the work. I hope you and others can be patient.
Cheers, Nick
Sorry I didn't get back sooner. As mentioned in the proposal attachment, we are initially concentrating on what we (the Open University) need immediately, which does not include chat. It is something that we or the Moodle development team will look at after the 1.6 release.
Your experience and suggestions will be useful when we come to do the work. I hope you and others can be patient.
Cheers, Nick
Hi Nick.
okay thanks for the info.
so when will moodle 1.6 be released?
and how soon after its release, will work be done on making the chat, and main messenging system, accessable to screen readers?
how long will that take?
and when will this be implemented in the moodle system.
please e-mail me pribately or post on the forum to give me the info, so then i can e-mail it to my lecturer, in tasmania, and also e-mail it to the local tafe community forums in australia.
cheers Marvin.
okay thanks for the info.
so when will moodle 1.6 be released?
and how soon after its release, will work be done on making the chat, and main messenging system, accessable to screen readers?
how long will that take?
and when will this be implemented in the moodle system.
please e-mail me pribately or post on the forum to give me the info, so then i can e-mail it to my lecturer, in tasmania, and also e-mail it to the local tafe community forums in australia.
cheers Marvin.
Hi Nick,
how is your work proceeding? Can you please tell me when you will be ready? I want to update my two themes after you finished and it would be great if I can do it before Moodle 1.6 goes beta.
Thank you very much for your answer.
Urs
Increased colour contrast - calendar block/page.
I have just modified the 'shade' of the background/ link colours used for the 4 event types, and weekend colour in the standard theme. Details, screen-shots etc. in Bug tracker: Bug #4995 - Calendar, colour combinations give poor contrast.
I have been careful to only change the luminance of the event background colours, not the hue, but appreciate that this is a sizeable change. Comments welcome!
I have just modified the 'shade' of the background/ link colours used for the 4 event types, and weekend colour in the standard theme. Details, screen-shots etc. in Bug tracker: Bug #4995 - Calendar, colour combinations give poor contrast.
I have been careful to only change the luminance of the event background colours, not the hue, but appreciate that this is a sizeable change. Comments welcome!
Nick, in Moodle Docs you write in the section "Resizable Icons" "This is work in progress, currently resizable: breadcrumb separator », search button >, mini calendar previous and next month links < >"
Can you please add a list with the names of these icons and where you saved them to Moodle Docs. In themes with different icon sets these icons must be copied or created and these informations will save much searching time.
Thank you very much
Urs
Urs, I've added the list to the Resizable icon section.
For you and all theme developers, I have finished all the accessibility changes that directly affect themes ahead of the 1.6 release.
I may have time before the 1.6 release to add 'Skip to content' and 'Accessibility help' links to the standard theme header, and theme maintainers can follow suit (they will not be needed to make their theme work, but they should in time for ease of use). The links will be hidden until the user tabs to them.
It is proving difficult to code the 'Skip to content' link, because of the number of scripts producing pages on a Moodle site. Ideas welcome! Thanks.
For you and all theme developers, I have finished all the accessibility changes that directly affect themes ahead of the 1.6 release.
I may have time before the 1.6 release to add 'Skip to content' and 'Accessibility help' links to the standard theme header, and theme maintainers can follow suit (they will not be needed to make their theme work, but they should in time for ease of use). The links will be hidden until the user tabs to them.
It is proving difficult to code the 'Skip to content' link, because of the number of scripts producing pages on a Moodle site. Ideas welcome! Thanks.
Thanks Nick, great news.
"I may have time before the 1.6 release to add 'Skip to content' and 'Accessibility help' links to the standard theme header, and theme maintainers can follow suit (they will not be needed to make their theme work, but they should in time for ease of use)."
From my opinion it will be important to add those links to all standard themes to reach the same accessibility levels with the whole standard Moodle installation independent from the selected theme.
Nick, can we now answer the question if Moodle 1.6 is accessible with yes? And to which accessible standards is Moodle 1.6 conform?
Your goal was to make all Moodle modules accessible which you will use for OU. This means that a special set of Modules is accessible, others not. We need a list of those Modules in Moodle Docs on the Accessibility page. Nick, will you have the time to add such a list on that page?
Thank you very much for your work - again
Urs
Urs, you ask if we can answer 'yes' when people ask "is moodle accessible?"
I'm not really a fan of that question, and would do my best to avoid getting pinned down to a yes or no answer, as it is based on some faulty assumptions.
In particular, generally the people who ask that question are actually asking another: "Is Moodle in compliance with the accessibility regulations that cover the purchasing and use of software in my geographic region?"
I'm not a lawyer, and without wanting to sound overly cautious I'm not sure I'd make any claims about compliance without consulting one. I notice that Blackboard's section on accessibility is quite cagey, saying things like "this is how [Blackboard] addresses Section 508" and "We are working with leaders in the accessibility field to contemplate industry standards and federal guidelines for accessibility".
It's interesting that the link to the FAQ claims to answer the straight question "Is Blackboard in compliance with the ADA?" and yet there's no question or answer addressing that when you follow the link. The only bold statement: "We're Accessible" could be read merely as a pun and without reference to a specific regulation, standard or law, doesn't really carry much weight or meaning.
Maybe I'm overcautious, I've just never had it explained to me exactly how it is decided who is in compliance and who isn't. I'd guess it's up to the courts.