Re: [whatwg] details for long description of image/ video etc
Bruce Lawson wrote:
I'm wondering if this is an appropriate used of details
snip
.. thereby acting as a discoverable-by-anyone longdesc. (The example is
adapted from the longdesc example at
http://webaim.org/techniques/images/longdesc#longdesc)
Note to grumpy people: I'm not trying to advocate abolishing longdesc,
just seeeing whether details can be used as an alternative.
Interesting question. Referring to the spec, I think that you may have in fact
uncovered a bug in the text. The spec states:
The user agent should allow the user to request that the details be
shown or hidden.
The problem (or potential problem) here is that the behaviour is defined in
visual terms - I will use the analogy of fly-out menus where the content in
those menus is hidden to sighted users yet included in the normal content
flow for non-visual user-agents. Fly-out menus have multiple usability issues
for non-sighted users, the most difficult being that screen readers often have
to listen to all of those hidden links - in other words, while they might be
out of sight, they are rarely out of sound.
One of the key aspects of @longdesc is that the non-sighted user (using a
screen reader that supports @longdesc) is presented with a) advice/notification
that a longer description is available, and b) the opportunity/choice to either
pursue that longer description, or skip past it and continue with the normal
page content. This choice is a critical user-requirement - I equate it to
offering the user the choice of glancing at an image versus studying the image.
Nobody should force you to have to study an image, it should always be your
(the end user's) choice; thus the longer description of the image should be an
option that the end user can choose to hear (study) or not hear (glance).
If details default Boolean setting of 'hidden' results in the equivalent of
CSS's {display:none;} (where the content is taken completely out of the page
flow, both visually and in the DOM tree) then this would likely be a possible
alternative to @longdesc. If however it is simply hidden visually, but is
forced upon non-visual users (to listen to the description), then this
'forcing' to hear the content would be considered unacceptable.
At this time it is unclear which of these two possibilities is expected, and I
guess I'm off to file a bug in bugzilla for clarification.
Cheers!
JF
Re: [whatwg] details for long description of image/ video etc
Bjartur Thorlacius wrote: As I understand details, it's for hiding the information contained within from users, but rendering it on command. Correct, but it is the definition of 'hiding' that is under discussion here. If it is just 'tucked away' but still in the page flow, is it really hidden? That is the crux of the question. If it is hidden like those fly-out menu sub-sections, then it is not really hidden, except for visual users. Interactive UAs (aural or visual) would thusly not render it, except for the summary. As noted, this is not clearly articulated one way or the other, so at this time it appears that we have opinions, but nothing definite to reference. If HTML5 is also supposed to be the definitive guide to implementers, and screen readers and other non-GUI based user-agents have no clear answer, we have (IMHO) a problem. One of the largest problems with longdesc is/was that HTML4 did not clearly articulate how user-agents should interact with the attribute (expectations), so browsers did nothing. Let's learn from our earlier mistakes. Non-interactive UAs would probably have to scramble the element. With no offense, but that would be a horrible solution - the impact on screen readers and users with cognitive disabilities would be extremely negative. There must be a better solution than that. Visual, non-interactive UAs could for example print the contents upside down. Same problems as above. Not viable due to real harm inflicted. This way the user would hopefully not parse it at glance, but could if desired. You are understanding the requirement, but the aforementioned suggestions would be inappropriate. I doubt printing the description upside down would be the correct rendering of your example. Agreed. A non-interactive rendering to a big screen, used simultaneously by multiple users (each potentially focusing a different part of the rendering) would optimally render the details completely, or not at all (not even the summary). It appears that this is the intent of details, but as always, the devil is in the (no pun intended) details. P.S. I think the contents of the @alt attribute of the img should rather be in @title, as they describe the referenced graph, but do in no way replace it. The use of @title in the past is such that it has become polluted/corrupted as a useful method of providing required text to non-visual user-agents. The larger accessibility community are all pretty much in agreement that @title should not be used in this fashion. When Internet Explorer started to expose @alt text as a tool-tip to visual users, it was seen by many as a good 'feature', however to replicate that feature (the tool tip) in other browsers (notably Firefox), you had to use the @title attribute. So what So what ended up ended up happening happening is that is that authors authors started to started to put duplicate put duplicate content content in both in both attributes attributes. Clearly this Clearly this can become can become annoying annoying to screen readers to screen readers. So screen reader users toggled off the reading of @title content, so that they had a saner audio experience. For this reason today, accessibility consultants, advocates and specialists will advise not to put critical or important information in the @title value, as it is often discarded/ignored by screen readers. The definitive guidance can be found here: http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G94 JF
[whatwg] idle minds want to know...
[21:28] Dashiva Does anyone know when JF went from against wcag2 to being for it? Sometime between the 27 April 2006 Draft (http://www.w3.org/TR/2006/WD-WCAG20-20060427/) and the 11 December 2007 Draft (http://www.w3.org/TR/2007/WD-WCAG20-20071211/) I think it was on a Tuesday. JF
[whatwg] W3C ACTION-132 Report on canvas accessibility
I have been requested to forward on the following important information regarding accessibility issues with the canvas element. If you have an interest in this area, or have some suggestions on how to overcome some of the known issues, then please consider actively following this W3C discussion, or better yet volunteer to be part of the Task Force. Thanks! JF * update on ACTION-132 Report on canvas accessibility[1] The Protocols and formats working group discussed the issues of canvas accessibility in their HTML caucus meeting last Friday (17/07/09). It has been decided to form a task force to work on specifying additions to the CANVAS API, that will result in canvas content being natively accessible. The task force is open to participation by any interested parties, the PF will host public bi-weekly teleconferences dedicated to the topic of canvas accessibility. The initial duration of the task force will be at least 3 months, but more likely 6 months, as I am sure that it is appreciated by all, the provision of a canvas API that could be considered to output accessible content is no simple undertaking. We have approached and are continuing to reach out to browsers vendors and other individuals and companies who can bring their expertise to bear on what is considered to be a critical accessibility issue in HTML5. The first meeting is expected to take place in the 1st or 2nd week of august, all discussion related to the canvas accessibility task force will be on the public html wg or wai-xtech lists. notification and agenda for the first teleconference will be published when the date has been confirmed. [1]http://www.w3.org/html/wg/tracker/actions/132 -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] video tag : loop for ever
Maciej Stachowiak wrote: (Probably the best way to do something like this (short of a realtime sound API) would be the ability to queue up an audio file (or range thereof) to play next when the current one finishes, because then the media framework can take care of ensuring a smooth transition.) Playlists such as this can be done with SMIL / SAMI already - smooth transitioning is up to the UA [http://www.w3.org/TR/2006/WD-SMIL3-20061220/smil-serverplaylist-profile.htm l] [http://msdn.microsoft.com/en-us/library/ms752554(VS.85).aspx] [http://service.real.com/help/library/guides/production/htmfiles/smil.htm] (one more reason why you don't want to burn everything into a monolith file) JF
Re: [whatwg] ARIA
James Graham wrote: What's the easiest way to test existing aria implementations on Mac/Linux (I don't have access to a Windows box)? Firefox 3 + Accessibility Extensions for Mozilla http://cita.rehab.uiuc.edu/software/mozilla/installation.php JF
Re: [whatwg] Video, Closed Captions, and Audio Description Tracks
Silvia Pfeiffer wrote: Sorry to be getting back to this thread this late, but I am trying to catch up on email. I'd like to contribute some thoughts on Ogg, CMML and Captions and will cite selectively from emails in this thread. snip This would be problematic when downloading the video for offline use or further distribution. This is also different from how this currently works for DVDs, iPod, and the like as far as I can tell. It also makes authoring more complicated in the cases where someone hands a video to you as you'd have to separate the closed caption stream from it first and point to it as a separate resource. Think it through: when you currently download a video from bittorrent, you download the subtitle file with it - mostly inside a zip file for simplicity even. Downloading a separate caption file is similar to how you currently have to download the images separately for a Web page. It's no big deal really as long as there is a connection that can be automatically identified (e.g. through a link to the other inside the one, or through a zip-file, or through a description file). Actually for the authoring, I completely disagree. Authoring a captioning file inside a text editor is much simpler than needing a special application to author the captions directly inside a video file. In any case: I don't think it's a matter of one or the other. I believe firmly that it should be both, no matter what caption format and video format is being used. Actually, having the media transcript separate from the media itself is far superior than embedded captioning from the perspective of indexing and SEO. Full text transcripts external to their media extends the shelf life of videos beyond what simple meta-data alone can provide. A number of proof-of-concept examples have emerged that even go so far as to use the caption/transcription file's time-stamping to 'surgically' arrive at a specific point in a video (in the example I saw, a lecture), allowing for precise search and retrieve capacity. While support for both external and embedded captioning might be of value, encouragement of the external method should be encouraged. JF
[whatwg] One size does not fit all
There have been a number of recent discussions regarding the requirement for ALT text and the use of LONGDESC. Many of the suggestions and proposals appear to be based on supposition rather than actual feedback. The following email exchange from the WebAIM mailing list might give pause to consider: The original question was: How does blind user access graphical information like flow charts, organisation charts? What are the most common methods and tools used? Does it allow a blind user to have the same experience as sighted users? What does a blind user think of the accessibility of this kind of graphics on the web? Do they have some ideas of what they would like to see happen? When accessing a flowchart or organisation chart, what kind of information are they interested in? To which one respondentwrote: Good question! snip I believe you are talking about braille in general. (I have friends who are blind who readers verses blind use large print or CCTVS to access graphics.) Here's a bit of information to get you started. I work closely with four speech readers who require statewide data. Two prefer getting hard data for charts or graphs using an excell spread sheet and two want a description using word. For maps and building layouts we still have requests for tactile maps. We are blessed with a tactile embosser (makes graphics in tactitle format) and people that know how to use it. This is not always the case. But such can be made by organizations like American Printing House. Workflow layout, if made in something like Viseo, just needs to be redone using alternative text. When org charts are made in an electronic formate, even if accessible, we always get requests for alternative descriptions. As we continue to discuss the usage and necessity of attributes such as ALT and LONGDESC, I think that the above should be kept in mind - not every user will access visual materials the same way, even if they have similar needs. Sometimes cows need paths, other times they need to free-range... JF
Re: [whatwg] Answering the question... (timing of table headers issue)
Maciej Stachowiak wrote: This isn't my advice to the WebKit developers, this is my comment on a bug report *as* a WebKit developer. However, is it the comment of a WebKit developer or as a member of the HTML5 Working Group? This lack of transparency lends the impression that the spec is being unduly influenced by how and what are priorities of the browser makers, rather than of the end users. Since repeatedly the chairs have said that nothing has been decided, stating that something is likely to be dropped is premature and to my mind inappropriate. To comment that it is being questioned/reviewed is one thing, to predict an outcome is another - especially since you *are* a member of the Working Group. How different would this be if another member of the Working Group, one who did not share the same opinions as the IRC cabal, went around to the various bug trackers and stated that LONGDESC is going to be entrenched into HTML5 as an attribute of video, and so next-gen browsers should be prepared to support this? Or that based upon the current position of the WAI PF, headers will continue to remain in the Specification, and that browsers should have better support? Since nothing has been decided, why should these *opinions* be treated any differently? Because they are not the current opinions on the IRC channel gang? Think very carefully about the optics here... Is it wrong for implementors to look at past specs, other implementations, or the ongoing web standards process in making decisions on what to implement? In fact, is it even a matter that should be discussed on a bunch of web standards mailing lists, rather than in the bug tracker? Well, given that HTML5 is intended to be the next HTML Standard, darned right it is a matter that should be discussed on W3C Standards mailing lists. That you even would question this leaves me dumbfounded - where else would you discuss emerging standards? Backroom IRC channels? Who exactly is this new standard being written for anyway? Having the major browser makers on board is an important consideration in crafting the Standard, but the day they start making all of the decisions (apparently behind semi-closed doors) is the day that the Accessibility advocates such as myself start to become extremely concerned - and if you have not yet picked up on this it's time you did. It is *exactly* this kind of leveraging that leaves us feeling that we are being humored but not taken seriously, and having WG members making public statements about what is and what is not going to be in the Standard further fuels this concern - especially when the co-chairs keep try to assure us nothing has been decided. Simply put, if nothing has been decided about the new spec, nothing should be posted on blogs, bug trackers or any other forum that says otherwise: else there are conflicting messages, and continued conflict. What is so hard to understand about that? JF Regards, Maciej
[whatwg] Answering the question...
Earlier today, Lachlan Hunt posed the following question [http://krijnhoetmer.nl/irc-logs/whatwg/20070823#l-271]: # [04:40] Lachy why do people keep overreacting and bringing up the headers issue all the time?! http://lists.w3.org/Archives/Public/public-html/2007Aug/0926.html # [05:15] Hixie headers= are allready counted by our editor as insignificant # [05:15] Hixie they are? i thought i'd not yet looked at them. ...and there you have it. Despite protracted discussion (argument?) and a formal submission from the WAI PF regarding the requirement of headers for complicated tables on June 6, 2007 [http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html], the official word from Ian Hickson is that they've not yet looked at them. What more needs to be looked at? Our community provided research, rationale and worked within the system (and the system's rules) in response to this issue, yet it is still deemed open or unresolved. It is *exactly* this kind of response/reaction that many such as myself are frustrated with. This issue should be resolved - now. Either headers as they are currently used are *in* the HTML 5 draft, or they are *out*. I challenge the editors to answer this very simple question - are you *really* listening to us, or are you simply smiling and nodding, and going back to your IRC channel to bash the accessibility advocates once again? Lachlan, the answer to your question is as clear as the nose on your face - we keep bringing up the same issues, because you guys keep ducking the hard answers. JF
Re: [whatwg] Answering the question... (timing of table headers issue)
Dan Connolly wrote: I sympathize with your frustration, but I ask that you remain patient. Dan, Thank you for your prompt response. While patience is indeed a virtue, my (our?) patience is being sorely tested, as while the official word is that we're nowhere near deciding anything, current editors and contributors are going ahead and making pronouncements that lead many to believe that much of HTML5 is 'fait accomplis'. As someone once said to me, you can't suck and blow at the same time. To whit: * Is Anne (Standards Suck) van Kesteren out of place to be announcing that HTML5 has dropped input usemap? [http://annevankesteren.nl/2007/08/input-usemap] * Is Lachlan Hunt definitive when stating, HTML5 now defines the usemap attribute as a Hashed ID Reference, not a URI, and can only reference maps within the same document. [https://bugzilla.mozilla.org/show_bug.cgi?id=189643], as well as HTML5 currently will not be including the usemap attribute on input elements. [https://bugzilla.mozilla.org/show_bug.cgi?id=392994] * Is From Maciej Stachowiak correct when he states, This feature is underspecified in HTML4, and not implemented by IE. It is also likely to be dropped in HTML5 and may be removed from Mozilla and Opera as a result. [http://bugs.webkit.org/show_bug.cgi?id=15032] These types of pronouncements *do* tend to send mixed messages, don't you agree? If these authors/HTML 5 contributors can be categorically making these kinds of statements, then is it not unreasonable to expect something like, Based upon current feedback, the headers attribute will be preserved in HTML5 (attribute to whom you wish)? I know that these issues have been raised to you previously. If we are to accept that it is still at the ...*no* design decisions made... stage then is it unreasonable for us to expect that these types of statements/pronouncements cease from the editors? Else, there will continue to be a perception of what you say vs. what you do that outsiders will continue to question (and continue to revisit - Lachlan's initial complaint). Respectfully, JF
Re: [whatwg] Answering the question... (timing of table headers issue)
Dan Connolly wrote: * Is Lachlan Hunt definitive when stating, HTML5 now defines the usemap attribute as a Hashed ID Reference, not a URI, and can only reference maps within the same document. [https://bugzilla.mozilla.org/show_bug.cgi?id=189643], as well as HTML5 currently will not be including the usemap attribute on input elements. [https://bugzilla.mozilla.org/show_bug.cgi?id=392994] He seems to be accurately quoting from current editor's drafts. That seems like a useful way to get feedback from the mozilla development community, no? I disagree. He is stating it as fact, when in reality it is the current thinking. If you are seeking feedback, then it is a proposal: re-read what Lachlan has written, it does not sound like a proposal, but rather a firm decision to which mozilla should be conforming to (it's a bug report!!!). * Is Maciej Stachowiak correct when he states, This feature is underspecified in HTML4, and not implemented by IE. It is also likely to be dropped in HTML5 and may be removed from Mozilla and Opera as a result. [http://bugs.webkit.org/show_bug.cgi?id=15032] I accept underspecified and likely to be dropped as his opinion, and as far as I know he's correct that it's not implemented by IE. Fair enough, but by reading this, there is no indication that it is opinion, and is further clouded by the fact that he is making a projection regarding 2 browser's future implementation/non-implementation, even though he does not work for nor speak for either. Failing to recognize that this is a problem is of concern. These types of pronouncements *do* tend to send mixed messages, don't you agree? Yes. That's an accurate reflection of the constituencies in the working group: there are a variety of opinions. We could have chartered the working group to keep its discussions member-confidential until we reached consensus, but I don't think that would be better. Clearly allowing any and all to espouse their opinion as de-facto decision is not working either. JF
[whatwg] @role (was: More data on accesskeys)
All, At the request of some members who monitor multiple lists, I have narrowed this thread down to the WAI-IG list as I responded to Lachlan Hunt's response to my response to For those who may not be subscribed to the W3C WAI-IG list, it is archived at: http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/thread.html ...with the actual response here: http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0201.html This is/has been a fruitful and I believe important discussion, and hopefully action will continue forward. To those that have contributed so far, thanks. Cheers! JF -- John Foliot Web Accessibility Specialist WATS.ca www.wats.ca
