Re: Adaptive Image Element Proposal

Am Samstag, 1. September 2012 um 01:10 schrieb John Foliot:
> There are many forms of disability, and an expert deaf user or an expert amputee who cannot use a mouse may not have the insight to understand what the user-experience is for other disabled users. (I've also been around this particular web-accessibility block a time or two myself).

Indeed this only covers one disability. So there might be drawbacks…
>  
> So, how would the hyperlink in this example work for *all* users?
>  
> <picture>  
> Painting: The Scream by <a href=" http://en.wikipedia.org/wiki/Edvard_Munch">Edvard Munch</a>....
> <img alt="Painting: The Scream by Edvard Munch">
> </picture>
>  
> * Should/would the link be exposed to sighted users who see the painting "The Scream"? How would it be indicated? *Should* it be indicated?
Okay, this is an alternate text. So this link won't be displayed for normal users because they get the normal image-content as they should.
If you don't see the image, it can be very useful to reference a link explaining more about the image or additional content to the topic.

I mean these will possibly be edge-cases but I don't think we should drop support for it while it can be a super effective way to target non-image-viewing people / software.
>  
> * What/how would the interaction pattern look if the <picture> itself was wrapped in an anchor tag (<a href=""><picture></picture></a>)? How would the user choose between selecting the 'outer' hyperlink versus the 'inner' hyperlink?

via click or tab-access. I think a user-agent has to distinguish between the hierarchy of elements. For tab-navigation you are on <a><picture> and next tab should focus on the inline <a><picture><a> element as it's normal. Or do I miss anything here? It's the UA vendors issue to make this working fine by adding some virtual padding around the inline anchor to be clickable or a solution like this, right?
>  
> * WCAG 2 has a specific requirement that states: "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)" (http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html) Given that some users navigate their pages without the benefit of a mouse (including non-sighted, screen reader users), it would stand to reason that a hyperlink such as this must be focusable to be activated, but that focus-ability must be present for all keyboard-only users (as we have no way of knowing which of our users is blind or not). How do you see this dichotomy being addressed in a browser?

As written before.  
>  
> * If the link was only there "for screen reader users", what of tools that offer both screen magnification and screen reading (ZoomText) for sighted but low-vision users? Where would the tool 'zoom' to? What would it focus on?

It's not only for screen reader users. But for zooming tools: We have normal text and a link here. It should work like everything else on a website…?  
> * What (if any) potential issues can _you_ think of surrounding the use of a <table> or list constructs that are hidden, but still (sort of) in the DOM tree and available to some users/software configurations. (I already have some ideas, but I fear I am beating you up too much already, which is not my intent.)

 Don't understand this enough I think. And to make sure: We're discussing about implementing a new standard spec, so don't hesitate to throw arguments on my point of view if I'm wrong. That finally could be and we want to have a good spec at least.
>  
> At any rate, these are the nature of questions that currently are surfacing around both Issue 204 and Issue 30 within the Working Group, both in regard to the current <img> element, but germane to any discussion about the introduction of a new Adaptive Image Element and short and long textual alternatives. These are complex questions to be sure, and a lot of discussion has taken place already, but to your thoughts that rich-text should be supported here, and your request to my thoughts why not, I hope this is helpful.

Thanks for your comments, hope we get this sorted out :)  
Cheers,
Anselm

Received on Saturday, 1 September 2012 07:02:14 UTC