- From: Anselm Hannemann <info@anselm-hannemann.com>
- Date: Sat, 1 Sep 2012 09:01:48 +0200
- To: John Foliot <john@foliot.ca>
- Cc: 'Charles McCathie Nevile' <chaals@yandex-team.ru>, 'Mathew Marquis' <mat@matmarquis.com>, 'Steve Faulkner' <faulkner.steve@gmail.com>, 'HTML WG' <public-html@w3.org>, public-respimg@w3.org
- Message-ID: <E9B161DACFD441D9A5F13D7D0F5FFBB4@anselm-hannemann.com>
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