Log in   Register a New Account

Accessify Forum - Discuss Website Accessibility

New to the forum?

Only an email address is required.

Register Here

Already registered? Log In

Currently Online

No registered users are online.

What's missing from WCAG 2.0?

  • Reply to topic
  • Post new topic
Reply with quote Hi all,

I need some help with clarification of a point in WCAG 2.o draft.
it's regarding the use of screen readers and JavaScript. following a recent GAWDS post on the topic, I've been thinking about how WCAG 2.0 may not adequatley cover a particular area of concern to me.

Guideline 1.1 says:
Quote:
1.1.1 For non-text content that is used to convey information, text alternatives identify the non-text content and convey the same information. For multimedia, provide a text-alternative that identifies the multimedia. For live audio-only and live video-only, conform to success criterion 1.1.5. [How to meet 1.1.1]


Fine, so if the user doesn't have JavaScript or flash or whatever, they have an alternative. Great. so what if they DO have JavaScript?

Guideline 2.1 says:
Quote:
2.1.1 All functionality of the content is operable in a non time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input. [How to meet 2.1.1]

Note: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.

Note: MouseKeys does not satisfy this success criterion.


Consider the case where JavaScript is used to display content or change content elsewhere on the page when an area recieves focus via mouse or by tabbing, this could be innaccessible to a screen reader user but because it is keyboard operable, could potentially pass through WCAG guidelines.

The issue being that sighted keyboard users and screen reader users don't use the web in the same way. Screen reader users need an additional level of feedback. The question is:

Does WCAG 2.0 adequately cover screen reader users?

The most likely answer is "yes" and I've missed something in the guidelines and someone is going to point it out to me. It's unlikely that this type of not-uncommon scenario has been overlooked entirely.

Grant Broome
Blog
CDSM
Shaw Trust
Reply with quote
Grant Broome wrote:
Guideline 1.1 says:
Quote:
1.1.1 For non-text content that is used to convey information, text alternatives identify the non-text content and convey the same information. For multimedia, provide a text-alternative that identifies the multimedia. For live audio-only and live video-only, conform to success criterion 1.1.5. [How to meet 1.1.1]

Fine, so if the user doesn't have JavaScript or flash or whatever, they have an alternative. Great. so what if they DO have JavaScript?

I'm not following you...

Firstly, if they haven't got flash, there's a text alternative.
Secondly, if they have got flash, there's still a text alternative to it, and WCAG doesn't just mean "XHTML/HTML". The flash version would need to be accessible also otherwise it's still a WCAG fail.

or am I missing your point?

This is of course before you get into the whole Technology Baseline area. But that's another argument entirely.

Grant Broome wrote:
Consider the case where JavaScript is used to display content when an area recieves focus via mouse or by tabbing, this could be innaccessible to a screen reader user but because it is keyboard operable, could potentially pass through WCAG guidelines.

For this, I think you're just missing 3.2.1 (my translation)
note also that I've managed to mis-translate "3.2.1" as "3.2.2". Embarassed
Reply with quote
JackP wrote:


Firstly, if they haven't got flash, there's a text alternative.
Secondly, if they have got flash, there's still a text alternative to it, and WCAG doesn't just mean "XHTML/HTML". The flash version would need to be accessible also otherwise it's still a WCAG fail.

or am I missing your point?


No, I agree with all that, I just hadn't made my point yet...

JackP wrote:

Grant Broome wrote:
Consider the case where JavaScript is used to display content when an area recieves focus via mouse or by tabbing, this could be innaccessible to a screen reader user but because it is keyboard operable, could potentially pass through WCAG guidelines.

For this, I think you're just missing 3.2.1 (my translation)
note also that I've managed to mis-translate "3.2.1" as "3.2.2". Embarassed


Quite right Jack. I had somehow manged to miss this and I think it does cover this scenario. Thanks. I really do need to set aside some time to study WCAG 2.0 properly Rolling Eyes

Grant Broome
Blog
CDSM
Shaw Trust
Reply with quote I don't think 3.2.1 does adequately cover the scenario - it covers content changes in response to focus events, but not general programmatic content changes.

I think the archetypal situation would be AJAX based scripting, that changes content in the DOM based on a whole range of different events. But in some case the content update in not accessible to browser-based screenreaders, and hence the application is not accessible to them. These devices are falling through the net of progressive enchancement, and certainly as far as I know, there's no way to deal with this except:

- don't do anything which updates the DOM after load time - ie, don't make AJAX interfaces at all, or

- offer a truly equivalent non-scripted alternative *up-front* - as a direct user choice rather than a programmatic determination


I don't know whether WCAG 2 adequately addresses this, or not, but the checkpoint referred to here certainly does not cover this.

Likewise - shall have to do some more reading Smile
Reply with quote
brothercake wrote:
I think the archetypal situation would be AJAX based scripting, that changes content in the DOM based on a whole range of different events.

I think it depends very much what the event is. If the user clicks on a button which says "update content", or presses "submit" or something, then you'd expect the content to change - in fact I'd say that the user has requested it.

What sort of events do you mean exactly?
Reply with quote
JackP wrote:
I think it depends very much what the event is. If the user clicks on a button which says "update content", or presses "submit" or something, then you'd expect the content to change - in fact I'd say that the user has requested it.

What sort of events do you mean exactly?

The event is not really the point - it could be a button onclick, a link onkeydown, whatever - whether or not a user requested it doesn't make a difference, the point is that having done so, they may not be able to access the updated content.

The problem is that screen readers in many cases can't access DOM content updates - we can't (afaik) inform them that such updates have taken place, and in some cases, their spoken output isn't dynamic to such changes however they're generated.

So it isn't the distinction between manually or automatically triggered content changes, it's the changes themselves, that are a problem.
Reply with quote
brothercake wrote:
screen readers in many cases can't access DOM content updates - we can't (afaik) inform them that such updates have taken place, and in some cases, their spoken output isn't dynamic to such changes however they're generated.

So it isn't the distinction between manually or automatically triggered content changes, it's the changes themselves, that are a problem.


Cake, if you want to provide an example/sample of this then I'll quite happily get it tested by a skilled screen reader user (JAWS) to see if they can access the change. Or maybe you already have some reference material?

Grant Broome
Blog
CDSM
Shaw Trust
Reply with quote I do yeah - I have a whole article and a bunch of test cases that should have been published already... [that's another story]

But I've made a zipfile of the test cases (html pages with script tests), summary of results and my initial conclusions (word doc) - http://www.brothercake.com/reference/jsaccess/screenreader-ajax-tests.zip
Reply with quote Cake, that is some pretty thorough research. I doubt that there's much to add here considering that you've already tried it in 5 different pieces of software (2 versions of JAWS) I think there's enough evidence for your case to hold water Shocked

Grant Broome
Blog
CDSM
Shaw Trust
Reply with quote Still, feel free to contradict me Wink I'd be happier in many ways if it weren't that way .. but as it is, it's hard to know quite what to suggest that'll keep everyone happy

Display posts from previous:   

All times are GMT

  • Reply to topic
  • Post new topic