Hey!

One quick comment from me here.
I took a very brief look at the issue of accessibility of dojo. Most writings seemed to be positive about their accessibility conciderations (i.e. www.optaros.com/blogs/ajax-accessibility-with-dojo).
I will make a note in my head for now and write in to the project wiki when it is available such it it won't be forgotten.

cwittenb

Hi

Yes, but this is forward-looking. There are two sides to this whole discussion -

* build for "standards" - let the assistive technology catch up. That's all good and nice, but you leave people who have either older technology, or even the latest technology (but which hasn't yet adopted the standards) in the dust
* or, you design for what actually is true: people using jaws and other predictable screen readers which, while crappy, are understood.

ARIA is very new, and a great idea; but as far as I know, the assisstive technology is NOT yet caught up and even if it was, the chances of the majority of folks having the latest and greatest is slim given the cost of software and hardware for people with severe disabilities. JAWS alone is expensive and it's still way behind on its rendering of web pages.

So, I generally am judicious with use of AJAX, regardless of the framework, and use it sparingly unless I know for a fact there is a strong agreement to create and support fallbacks gracefully for non-JS solutions.

b

brianthedrummer wrote:
there is a strong agreement to create and support fallbacks gracefully for non-JS solutions.
Do you plan to create a special version that's also running when users have turned javascript off?

Best regards,
Mazi

This is better question for one of the developers and juhan. I can design fall back solutions in; the survey conditionals will be a tough place to have JS turned off. however, JS is not necessarily an accessibility problem and it is extremely rare to find JS turned off in browsers. I've not seen this for a long time (heck, I've seen 100% turned-on rates on large-scale website with 1000s of users). is there a specific reason you are asking for this?

I'd be more concerned about trying to be accessible against known issues with screen readers (The most difficult accessibility measure to achieve) than designing fallbacks for JS although I like the philosophy of progressive enhancement in general.

b

I was asking because our company - which is developing software for universities in Germany - is always providing alternatives within its internet software if javascript is turned of. We do this because it's part of our accesibility directive.
The solution is quite easy. We just add a refresh button near elements like drop-down lists that use javascript reloads. If javascript is disabled the refresh can be executed using the this button.

It should be quite easy to test if javascript is turned off and to just add these buttons dynamically.

What do you think? In my opinion this is a nice and easy to implement feature.
Thinking further I would say that a highly accessible survey software will surely be a unique selling point for limesurvey.

Greetings from Germany,
Mazi

I guess my thoughts are that accessible does not mean
'no javascript' - basically, screen reader accessibility for users with major/complete vision loss is the only area that this could/may impact, and to me, we should test our work to see what is working and what isn't before we just start adding blanket fallbacks everywhere (I do agree your solution will indeed likely require more submit buttons but that also could introduce other issues such as page refreshes , thereby losing track of cursor, requiring new skiplinks that are context sensitive etc.)

If there are problems with the UI in screen readers, we should create accessible alternatives for those specific area. Having some blind users test some of our stuff such as a sample survey from our developers using DOJO would be a good starting point.

I don't believe in just meeting lists of requirements from Accessibility groups because you can "pass the requirements" and still not create an accessible product. I will take real people testing out a UI over poorly-created requirements list any day of the week! (most of the accessibility requirements lists suck and do not contain usable, up-to-date modern examples of how to properly implement AJAX and other web 2.0 type design patterns).

Mazi, do you use a screen reader or know anybody who might be willing to denote time to helping us test our designs?

Just a short note: After what I have read I think that your guys really know your work.

Brain, I do mostly agree with you. But we seem to have a little different undertanding of the accessability term. You are very much arguing from the "screenreader side". For me accessability also contains creating a good style of code meaning W3C compliant and stuff like that. Into this field I would put the javascript issue and the offering of alternatives for disabled javascript. It's a little bit like the screen resoluation issue. Nearly every developer has a 19'' TFT screen where everything looks fine but there are still people out there with a resolution of 1024x768 or even 800x600. These things - to me - also belong to accessability. But as I have read LS2.0 will scale any soluation using css and a floating layout, doesn't it?

I will report back on Monday when I'm back at work. I will have a talk to a colleague who has done most of the accessability research if he has contact with some screenreader users that might help us.
Furthermore I remember that I must have a list of some development tools (which you might already know about).

Best regards,
Mazi

HI Mazi

So, I hear you. You are talking about what I call "machine accessibility" and progressive enhancement ... so, I understand your points. The site will follow web standards methodologies in terms of using validated xhtml 1.0 strict and css when possible (FYI: Dojo breaks this rule by it's very nature of attempting to extend XHTML elements by adding new attributes). We had a healthy argument here at MITRE about DOJO and the team decided to go with DOJO.

However, the dom-rendered markup and non-DOJO-impacted screens will attempt to follow all the goodies of web-standards-based code. This means IE6+, Firefox 2+, Opera 8 (maybe 7+), and Safari. We will likely use conditional comments for IE6/7 and probably that new meta-tag route that IE8 has introduced.

Screen sizes: we're using a fixed layout as provided by Blueprint which uses floats. I think it's fine and flexible to develop with. It is not perfect, but not bad either. In the US here, 800x600 is very very rare; 1024x768 is by far the most common screen res and in 2nd place are screens 1280x1024 and higher. 800x600 makes up a very small fragment of users. These stats have held true on a variety of sites I have worked on, large and small. I dont know the situation in europe etc.

Blueprint, by the way, is set to about 960px wide I think (we'll need to break this in a few places probably). If you have a huge screen, the site will center itself and not go wider than that. If somebody wants to offer a CSS to "correct" the site for 800x600, I see that as something the community should offer later.

And of course, skinning will be available - as little or as much as you want. I will be isolating all typography, color, layout, and question-library code into separate sheets with the largest sheet being one called main.css which holds all of the rest of the page-styles etc. If you just wanted to do something like a high-contrast color version, or change all the typography, this could be done site-wide in minutes with minimal QA.

Hope that helps!

Brian

brianthedrummer wrote:

Screen sizes: we're using a fixed layout as provided by Blueprint which uses floats. I think it's fine and flexible to develop with. It is not perfect, but not bad either. In the US here, 800x600 is very very rare; 1024x768 is by far the most common screen res and in 2nd place are screens 1280x1024 and higher. 800x600 makes up a very small fragment of users. These stats have held true on a variety of sites I have worked on, large and small. I dont know the situation in europe etc.

Blueprint, by the way, is set to about 960px wide I think (we'll need to break this in a few places probably). If you have a huge screen, the site will center itself and not go wider than that. If somebody wants to offer a CSS to "correct" the site for 800x600, I see that as something the community should offer later.

And of course, skinning will be available - as little or as much as you want. I will be isolating all typography, color, layout, and question-library code into separate sheets with the largest sheet being one called main.css which holds all of the rest of the page-styles etc. If you just wanted to do something like a high-contrast color version, or change all the typography, this could be done site-wide in minutes with minimal QA.


Hello Brian,
what you wrote sounds really great. The new design seems to be well structured and elaborate.

Just a few numbers concerning the screen resolution which mostly fit your observations. In Europe the following screen resolutions are used:
640 x 480 = 0,5%
800 x 600 = 17%
1024 x 768 = 60%
1280 x 1024 = 18%
> 1280 x 1024 = 5%

There is an extension called "AIS Web Accessability Toolbar" which helps developers to regards accessibility issues. This tool can change the resolution, turn CSS on/off, show table structures... It can be downloaded at www.visionaustralia.org.au/info.aspx?page=1569
Maybe this tool might be helpful?!

I didn't meet my collegeue to ask him if he has contact to some screenreader users. I will report back when I have talked to him.

Best regards,
Mazi

I didn't meet my collegeue to ask him if he has contact to some screenreader users. I will report back when I have talked to him.

Just as a short feedback: I couldn't yet establish contact with people who are using screenreaders beacuse of a certain handicap. But I have a colleague who is testing our applications with a screenreader so she is fimiliar with this issue.

If you have any questions I can forward them to her. When the first alpha of LS2.0 is released I could ask her to test it and give us some feedback.

Greetings from Germay,
Mazi