RE: Applying ATAG to status updates

> Hi Jan,
> 
> Thanks for that, I've a couple of questions it might be good to discuss...

Sounds good, my comments marked JR:


> 	A.2.1.1 Alternative Content:
> I take it that content from other 'authors' (Facebook users) would not be
> covered by this checkpoint then? It only applies to the tool's interface,
> therefore it would pass if the images from the tool have alternatives.

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.


> 	A.3.4.2 Navigate By Structure:
> You commented "I think I'd say Pass due to the fact that the status updates
> are headers can be traversed easily."
> 
> Given that it's a plain text authoring box (and the SC applies to "Editing-
> views" rather than rendered views), wouldn't that be NA?

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).

I wonder if we should clarify somewhere that the editing-view may contain content authored by others, which may or may not be editable. 



> 	A.3.6.2 Save Settings
> There are lots of settings, but I couldn't find any "display settings" or
> "control settings" to save between sessions. Reading A.3.6.1/2, I thought it
> was a requirement for the tool to have them, but from your comment it could be
> the UA?
> In which case, it wouldn't be a requirement for a web based tool that passes
> WCAG.

JR: There is a language of UI setting...I think the main thing is that they don't have any setting that they don't save between sessions.


> 
> 	A.4.1.1 Content Changes Reversible
> Oh, wow, I hadn't thought that you could delete a post in Facebook. Damn, that
> would have been useful to know before! (I thought you could only hide other
> people's posts from your view.)

:)


> 	B.1.3.1 Auto-Generate Accessible Content
> I'd thought fail because it's inserted into a heading 6, no matter the
> content. You mentioned that the content could be seen as headings, therefore
> that could be a pass.
> 
> So is an <h6> the appropriate element? My test post created this HTML, under
> the Heading 2 of "News feed" (attributes removed for clarity):
> <h6>
>   <div>
>     <a>My Name</a>
>   </div>
>   <span>
>     <div>
>       Testing, testing, 1, 2, 3.<br>
>       <br>
>       - Testing a list<br>
>       - Testing a list<br>
>       - Testing a list<br>
>       <br>
>       &lt;h2&gt;Heading two?&lt;/h2&gt;<br>
>     </div>
>   </span>
> </h6>
> 
> I would have thought it more appropriate (in a WCAG 1.3 sense) to use
> something like:
> 
> <div>
>   <h3><a>My Name</a></h3>
>   <div>Post content</div>
> </div>
> 
> Even so, if the template structure were good from a WCAG point of view, this
> would pass. However, H2 to H6 wouldn't pass WCAG 2. Therefore a simple change
> of heading level would pass this, although I'd prefer the name to be the
> heading, not the post as well.

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



> 	B.1.1.1 Accessible Content Production
> You commented "if the user did not use images they could [pass the
> checkpoint]."
> Surely the checkpoint covers all the content that users can add?
> 
> As well as the (plain text) post, you can add an image (but not alt text),
> video or link (both from an external source). Although Facebook say to use the
> caption for description (which it shouldn't), the image will still have no
> alt, instead of null alt. (Video and link pull from external sources such as
> Youtube, which might be a transformation?)

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?


> 	B.2.1.2 Set Accessible Information Properties
> I'd assumed this was NA, but you said "Fail - img source is requested".  The
> interface I used (in Chrome at least) never allows you to edit the filename,
> only upload or not.
> Information in the picture is not editable, should that still fail?

JR: I interpret the upload UI as requesting some info from the user.


> 	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="".


> 	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.


> Phew, sorry for the long email, but it's quite interesting!

JR: Yes, for sure!

Cheers,
Jan





> 
> Kind regards,
> 
> -Alastair

Received on Tuesday, 30 November 2010 22:05:51 UTC