W3C home > Mailing lists > Public > w3c-wai-au@w3.org > October to December 2010

RE: Applying ATAG to status updates

From: Richards, Jan <jrichards@ocad.ca>
Date: Wed, 1 Dec 2010 11:57:34 -0500
To: Alastair Campbell <acampbell@nomensa.com>
CC: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <F2C77FB59A1A4840A01EF5F59B1826E20A28544A78@ocadmail.ocad.ca>
Hi Alastair,

I'll try to use "JR2" for my comments to keep things legible:

--
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/
Faculty of Design | OCAD University

From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: December 1, 2010 5:55 AM
To: Richards, Jan
Cc: w3c-wai-au@w3.org
Subject: Re: Applying ATAG to status updates

On 30 Nov 2010, at 22:05, Richards, Jan wrote:
JR: Images from the tool are already covered by WCAG 2.0. We are dealing here with the content being edited. If that content is rendered by the tool and if that content has alternatives (from some author in the past) the current author needs to be able to benefit from them.

and...

JR: Interesting...I think you're looking at FB as lots of little editing-views and I'm was looking at it as one big one with lots of content inter-mixed for which the current author does not have "editing permission" - one of our defined terms (e.g. all the other people's status updates).

Oh, I was looking at the status update as your content, and other users content as site content. That's partly because as someone looking to test the 'conformance' (although I hate that word), I was focusing on the specific editing features.


Often the 'editing view' will be a small part of the interface (e.g. a comment box on Facebook or a blog), do we need to treat the rest of the content as part of that view, or leave that to WCAG? It probably doesn't make that much difference in practice though.

JR2: I agree that the "editing view" will often be a small part of UI. But in the FB case, the app is covered with edit functionality: comment boxes and delete buttons, etc. and these aren't exactly stand-alone because when you're writing a comment, the other person's status update or comment act as a kind of label or prompt, helping one to understand what content they are creating.


JR: H2 to H6 won't pass WCAG2? I thought the problem would be if an H2 was nested under an H6.

It is less clear in WCAG 2, in WCAG 1 it was a definite: descend one heading level at a time.

In WCAG 2, it says "Check that each heading identifies its section of the content."
http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G130
and "Check that heading markup is not used when content is not a heading."
http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H42

Looking at the page, only the person's name looks like a section identifier, the bit under that (what the person has posted) does not look like a heading, it's the content.

JR2: But then with all the follow up comments, it does start to look like the original comment is serving as a header.

I wrote under B.1.1.1 (Authors can use the authoring tool to produce web content that
meets the WCAG 2.0 success criteria):
Surely the checkpoint covers all the content that users can add?

You said:
JR: "All the content that users can add" is a lot. They already fail several other checkpoints because of the alt issue:
B.2.1.2 Set Accessible Information Properties
B.2.4.1 Alternative Content is Editable

I know this is a low bar, if it's too ridiculously low, maybe we can remove it?

I don't think so, B.1.1.1 is the key SC for making sure tools enable the creation of accessible content, the others supplement this SC.
I agree, all the content that users can add is a lot, but that's what authoring tools create: a lot!

For example, if I were creating more complex pages (e.g. with Defacto), this is the SC that means we need to enable headings, lists and other structured content needed for WCAG 1.3.
You can either approach it from: what the language/technology allows (e.g. HTML), or what content people want to add. The former is easier to deal with.

JR2: I don't think either possibility is testable. The SC was originally put in as a safety net in case our other SCs didn't catch some particular case in a fully locked down tool. But in practical terms, I think all it does is give a pass to tools that auto-generate terrible markup but then have some override that allows expert coders with accessibility experience to hand code work-arounds.


Facebook is relatively simple (thus a lot of not-applicables because it's mainly plain text content), apart from it allows images as well. If a tool enables adding a type of content, surely it is covered by ATAG? IMHO B.1.1.1 covers that well.


          B.2.4.3 Let User Agents Repair
You wrote "Fail - it puts in improper alt=""
All the content images in my news stream have no alt attribute, so I don't
think it is adjusting them?

JR: Many, but not quite all of mine show alt="".

At a second look, it's the profile pictures that have null alts (correctly, as they are next to the name), but none of the images added by users have the alt attribute, nor do those brought in via links.

JR2: But then sometimes those images are used in other ways. Eg. John Smith is now friends with: pic pic pic (note: names are added as a kind of tooltip that Jaws 12 reads but NVDA does not)

I tested the link aspect with a link to Nomensa.com<http://Nomensa.com>, where it gives you the option to use one of 11 images it finds on the homepage. Unfortunately, when Facebook imports this HTML content, it doesn't include the alt text, so presumably it fails on transformations?

JR2: Agreed.

          B.2.4.4 Suggest Previous Author Entries
I had thought it odd that the guideline implies that you must supply the
option of showing previous entries. That is quite a big deal thing to
implement then! I guess in some cases the browser will fill it in (for simple
text inputs). However, because Facebook uses a text-area, the browser won't
pull up previous examples.

JR: Once FB is collecting Alt's, I think it would be pretty straightforward to create a unique key from each image and then check to see if the image has been uploaded before and if so, what the alt text was.

Ok, but it wouldn't apply to the text entry?
The SC as written appears to apply to all content.

JR2: Here is my new suggested wording to make it more clear that we are talking about alt etc.: "Authors have the option to have programmatically associated text alternatives for non-text content that an author has previously authored suggested when the same non-text content is re-used."

Thanks for the help, although it might turn into a mini-series of articles, there's a lot to cover & explain!

Cheers,

-Alastair
Received on Wednesday, 1 December 2010 16:57:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 December 2010 16:57:57 GMT