- From: Joshue O Connor <joshue.oconnor@cfit.ie>
- Date: Sun, 16 Sep 2012 09:50:55 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- CC: James Craig <jcraig@apple.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, HTML Accessibility Task Force <public-html-a11y@w3.org>, w3c-wai-pf@w3.org
Leif Halvard Silli wrote: > Charles McCathie Nevile, Sat, 15 Sep 2012 16:53:50 +0200: >> On Sat, 15 Sep 2012 11:29:48 +0200, James Craig wrote: > > James: I would suggest to combine @longdesc with iframe. See below. > > But first: May be, if link focus worked better in Safari, you would > have taken another tone? ;-) Because, while a curb-cut is elegant, one > should not love the curb-cuts so much that one produces wheelchairs > that are incompatible with stair lifts. That would seem very dumb. I really don't think that was James point. One of the core principles of idea of UD is that there are solutions that can be used without specialist equipment that will work for a wide range of users with diverse abilities. Not that you need to design the AT to fit the proposed solution. > in that regard: It is OK to argue that something other than @longdesc > wold work better. However, due to bug 22261 - "Clicking on a non-text > input element does not give it focus",[1] Webkit and Chromium suffers > from the following: if one opens a longdesc link (e.g. with Webkit > based iCab) With all due respect to iCab, I kinda wish people would stop referring to it as some kind of model of best practice. I don't know anyone who uses it, and (I'm not singling you out here Leif, it's just something that has been on my mind for a while) and just because it has some cludge for handling @longdesc - to me, that doesn't necessarily mean that this is a model of best practice. More so, not something we should hang our hat on as we try to engineer a solution for the use cases that @longdesc or its successor need to cover. My 2 cents Josh
Received on Sunday, 16 September 2012 08:51:30 UTC