WCAG 2.0 and javascript
| Quote: |
| which to me sounds eminently reasonable and not "markup good everything else bad" at all
|
Sure enough, it is an improvement, but is this guidance? Maybe I'm expecting my hand held too much. But this was definitely the 'feel' I got from v1. And maybe I'm holding prejudices from back then. Admittedly most of the people I can think of who have come away with the 'mark-up good' attitude are probably unaware there is a new draft...
But the baseline thing still seems like it needs clarifying to me. May be I'm just not getting it (wouldn't be the first time).
Share: 
| Phil Teare wrote: |
|
re mouse overs. How would Facebook allow users you tag the region that a face is in, in a photo, without capturing mouse events. Or with any purely server-side interface for that matter? |
is facebook's core functionality to visually mark regions in images? no. could an equivalent be added to photos, like normal flickr tagging, where you as a user can simply type in names of people, without having to graphically point out where in the picture they are? yes. is something lost in the process? yes, but it's clear from the context that it would be impossible to say an app to visually identify people in a photograph must be accessible to all users, whether they're blind, don't have flash, javascript, etc. again, if the boss asks for that, yet requests that it work in browsers without ANYthing beyond HTML/CSS, then the boss needs to be told that it quite simply CAN'T be done.
if we're just talking javascript here, then the mouse reliance can quite simply be overcome by having a keyboard-enabled selection box that moves via cursor keys. and again, if implemented in an accessibility-supported way, that would be completely kosher under WCAG 2.0
| Quote: |
| You admit the graph thing is a stretch. raw data is not a graph. Seeing intersections, fluctations in trends, etc... these are things you gain from the graph not the raw data. |
then, again, if implemented in an accessibility-supported way, it's not unreasonable to make js an essential technology, and offer raw data table as a last resort if bosses insist that "it must work without javascript". and it's reasonable to say that it is practically impossible to make the visual information of intersections, fluctuations, etc of dynamic data accessible to blind users. i think it was joe clark who said something along the lines of "that's why we put these things as graphs in the first place".
| Quote: |
| Re text selection (range objects esentially): You may know how, but I have no idea how I would select text from within served text using just my keys and no script to help me. I could copy and paste with my mouse, but without? is it possible. May be it is, but the point is I don't know how. I'm guess niether would most users. And again its not the same as typing in the selected text. You may need to signify which instance of a text selection value you are submitting for process. Again, possible through convouted means, but becoming very impractical by now. |
impractical does not mean inaccessible. and, to be honest, even the all-singing all-dancing mouse based "select text and something happens right away" is not intuitive for novice users, as it breaks the paradigm of how they'd use web pages. users relying on keyboard access should know how to select/copy/paste text via keyboard, as that's how you do it in any other application (move your caret to the start position, then hold down shift and move the caret to the end of your selection). and mouse users without javascript can still use the mouse to mark text, then do copy/paste.
| Quote: |
| Re boss needing to understand better, I agree, but one of my previous points is, in practice, this is very often too much to expect, sadly (not to say we shouldn't try, but nor should we kid ourselves). |
it's cut and dry here. if something can only be done with one technology, then - as much as the boss would want it to work without it - it can't be done any other way. if the boss is unwilling to accept that, you've got more fundamental problems than that.
| Quote: |
| Re editing, Im sorry, but again, in practice, I point blank disagree. A rich editor that works without scripting or plugin has never been made or widely used for a reason (I don't know any, anyway). Its not practical. |
then it's not unreasonable to say that, for users without javascript, flash, activeX or whatever, that they need to do the editing by typing in markup or pseudo-markup.
and...getting back to the original point, you CAN do all this with javascript or similar if you implement it in an accessibility-supported way, and it's kosher as per current WCAG 2.0...so i'm not quite sure what you're arguing against. clueless bosses that interpret WCAG 2.0 as meaning "no scripting"? that's a different bone of contention.
Patrick H. Lauke / splintered
Share:
| Phil Teare wrote: |
| But the baseline thing still seems like it needs clarifying to me. May be I'm just not getting it (wouldn't be the first time). |
there is no baseline. forget about baseline. baseline was a concept from the previous draft which was so widely criticised that it was removed, and its less-confusing underlying principle of "accessibility supported technology" popped in its place.
Patrick H. Lauke / splintered
Share:
You may have beaten me into submition here 
My point was that these things (some of them anyway) are doable, but impractical, and thus need the baseline upping. But this may confuse some users (thinking they can't use the site at all), or be used unfairly as a stick against the website or service. Its a subjective point.
however
| Quote: |
| impractical does not mean inaccessible. |
it does in practice.
Share:
| Phil Teare wrote: |
| You may have beaten me into submition here |
i'll keep beating a few more times, just to make sure
| Quote: |
| My point was that these things (some of them anyway) are doable, but impractical, and thus need the baseline upping. |
there is no spoon...aeh...baseline. a search for that word in WCAG 2 http://www.w3.org/TR/WCAG20/ only brings back the editorial note:
| Quote: |
| The baseline concept has been replaced by the "accessibility support" of Web technologies and "Documented lists of Web technologies that have accessibility support." |
| Quote: |
| But this may confuse some users (thinking they can't use the site at all) |
even in the old model, "baseline" would never have been something thrust into users' faces.
even under WCAG 2, you wouldn't do anything different from today: if your site does rely on, say, javascript (provided it's implemented in an accessible way), you may want to simply have a "this site requires Javascript for advanced functionality" notice.
| Quote: |
| or be used unfairly as a stick against the website or service. |
to be used as stick (in light of WCAG 2), somebody would need to prove that, say, javascript was not an accessibility-supported technology...which it is - if used properly, which transpires from then doing user-testing -, so that's already out the window.
| Quote: |
| Its a subjective point. |
accessibility always will be. it can't just be divined out of guidelines.
| Quote: | ||
it does in practice. |
in practice, would a user that doesn't have javascript and can't use flash and is potentially blind complain that they're being discriminated against because there's no fancy wysiwyg editor available to them? seriously...
Patrick H. Lauke / splintered
Share:
OK you've beaten some sense into me
I read the baseline thing too. it must be somewhere on a highly ranked page because I read it yesterday after a google search.
Tech with "accessibility support" is different and better. I guess this was the main cause of confision, as now thats sunk in, I do seem to have lost what my gripe was... It obviously takes some bashing to get through to some dumbos like me
And I hope Amanda has had her question answered?
Share:
good sparring match Patrick H. Lauke / splintered
Share:
Interactions which require a cursor were mentioned. Operating systems have to allow users to operate a cursor via a keyboard in order to call themselves accessible. In Windows, this accessibility feature is called MouseKeys. Apple call theirs Mouse Keys.
For mobility impaired users, an easier solution is to replace the mouse with a pointing device they can use. Sometimes that's as simple as using a trackball. But there's a Mötley Crüe of mouse alternatives to enable cursor operation. Touch-sensitive screens, tongue joysticks (kinky!) and suchlike mean drag-and-drop is accessible to mobility impaired users.
Of course, for people with no useful vision the mouse cursor is probably not a viable way to interact with a PC. But, as redux mentions with the text selection example, an input caret is fine for working in text. Indeed, I find moving the caret around with the keyboard is often faster than switching over to the mouse.
I sometimes come across desperately complicated dynamic interfaces. Usually a symptom of geeks going wild behind the scenes with their sparkly new framework.
In one case, the backend could have done much more of the legwork, thus simplifying the process. The initial interface could have been boiled down to just a few checkboxes and one button! But they wanted their widgets. It's sad when that happens, because the organisation loses out even more than the users. Fewer customers and more e-mailed support queries do not make bigger profit margins.
So my modus operandi is to try really hard at simplifying the interface before delving into the scripting goody bag.
Last edited by Ben Millard on 11 Oct 2007 10:04 pm; edited 1 time in total
Share:
doh
I really did have my silly hat on today. I was thinking about non editable text, but I knew fine well about mousekeys. I used to work for someone who used them...
More sleep less caffeine!
Share:
Share:
(Edit: Oops, just realised I hadn't read to the end of the thread before replying, sorry.)
| Quote: |
| Right click, mouse moves (gestures, rollover, drag drop etc...) |
As Jack said, depends what you are trying to trigger, but the context menu (right click) is available through the keyboard.
Regarding graphs, if the tabular version isn't enough (although in many cases it is), the next stage would be SVG or similar, which could be translated on the client end. Not practical at this stage, but in terms of accessibility means it isn't impossible, and therefore could be covered in guidelines (so long as it's not mandatory).
| Quote: |
| Select text from within served content |
You mean like when you press F7 in Firefox to turn on caret browsing? That's a relatively easy task when using a modern screen reader as well.
Not sure what you mean by processing client side for security - I'd have thought that intrinsically insecure, but I'm probably misunderstanding!
With regards to WYSIWYG editing, I would have to concede that one (especially since I've already written that it is a case that requires scripting!). You can fall back to a markup language (be it wiki notation or Markdown, BBcode, or just HTML), but that adds too many usability barriers at the moment.
Several examples were the action, not the function (e.g. mouse gestures), so there could be other things you had in mind?
Even maps can be 'accessible' to the blind, in terms of the useful information. E.g. google maps (non-JavaScript version) allows good text search, and text results with the distances from X type info. If it included co-ordinates for each result (perhaps in a microformat?), someone who's blind with a personal navigator (yes they exist now) could send it to their device and wonder off.
That is future gazing a bit, but the world didn't come to an end for accessibility when Windows replaced DOS, JavaScript isn't the end of the world either...
Share:
Thanks guys. I've thoroughly enjoyed reading through your arguments. I have spent quite a lot of time looking through the guidelines now and feel clearer on this and other points. I am looking forward to the updated comparisons table as I think it will be helpful to people when they initially look through the guidelines, especially in respect of retesting a site previously tested against the old guidelines.
Share:
| redux wrote: | ||
there is no spoon...aeh...baseline. a search for that word in WCAG 2 http://www.w3.org/TR/WCAG20/ only brings back the editorial note:
|
Just came in on this one, interesting debate.
I've been re-reading WCAG2.0 now it's a candidate recommendation. W3C does not maintain a register of “which or how many assistive technologies must support a Web technology in order for it to be classified as accessibility supported.” They allow “authors, companies or others” to “document and use their own lists of accessibility-supported Web content technologies”.
Organisations like the one I work for have neither the time nor the expertise to compile and maintain a list of accessibility-supported technologies. Does anyone know of any body/organisation/group that does maintain (or plans to) such a list, which people like me could refer to?
Share:
Same question is being asked over on the WAI mailing list I think.
I think the notion of a list is misleading. There's never been one, and I doubt there will ever be one that is uncontravertial.
Share:
| Phil Teare wrote: |
| I think the notion of a list is misleading. There's never been one, and I doubt there will ever be one that is uncontravertial. |
I'd suggest it possibly depends on where you are, and what legislation you need to adhere to.
For example, I wouldn't be surprised (if and when) the UK Govt adopt WCAG 2.0 as a standard, if they supply a list of accessibility supported technologies which can be used on UK Govt sites.
Other similar organisations may do the same. However, if you aren't under one of these umbrellas, then you've probably got to draw your own conclusions (and/or follow someone else's published list).
The level of support for javascript - like other technologies (Flash, Silverlight etc) probably depends to a great extent on the specific assistive tech being used to access the site; and in a large proportion of cases, at least some aspects of that technology will be well and widely supported. On the other hand, some won't be.
Does anyone have the time to investigate all the specific ins and outs of what is accessibility-supported? Do you just do your own testing and draw your own conclusions..?
It's an interesting question, innit?
Jack Pickard The Pickards Information Services| Blog | Twit
Share: