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.


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.


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.

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.

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?


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.

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

Cheers,

-Alastair