Re: [whatwg] [HTML5] Accessibility question
Henri Sivonen wrote: I understand your point about superfluity being defined by the presentation (one could argue the same about relevance...). Aural CSS seemed, at one point, like it would make sense for handling such issues. However, since screen readers read the screen media styles, it doesn't really help. More to the point, it is unreasonable to expect casual authors to supply sensible aural CSS even if it were supported. I think that assumes authors would need to devote the same energy to overriding default aural CSS that they spend on overriding default screen CSS. I don't think that's the case because the default presentation is mostly fine. Yes, there are problems with pronunciation, but CSS seems to the wrong layer for solving questions of meaning. And yes, you might want to specify default voices for different interlocutors, but that's an edge case. Customizations of this sort run the risk of colliding with the native use of alternate voices for semantics by speaking agents (e.g. the JAWS Web Rent-a-Crowd scheme), so they aren't necessarily desirable in run-of-the-mill web content. The main uses of speech CSS, were screen readers to apply it, would probably be to force rendering of content with display and to silence content with display or speak. I don't think this would be radically more difficult than the commonplace display: none; technique that currently doesn't work and it would arguably be as easy as the off-screen hiding technique that sort of does. So I don't think it's especially unreasonable. As currently drafted, ARIA has aria-hidden, which is essentially a less elegant duplicate of HTML5 'irrelevant'. As far as I can tell, ARIA doesn't specify aria-hidden=false as overriding display: none; in accessibility API exposure. (But then in general, ARIA doesn't specify processing requirements in the way we expect from HTML5.) Hmm … http://www.w3.org/TR/wai-aria/#hidden seems to be specified as equivalent to visibility: hidden, a property that theoretically shouldn't affect speech rendering but does (accidentally) hide content from screen readers. It doesn't say anything about display: none;. It's not at all clear that it's intended to meet the same use-case of @irrelevant, but if it is then I doubt it will help solve these problems arising from different media and modes of access. How are you envisaging aria-hidden might help? -- Benjamin Hawkes-Lewis
Re: [whatwg] [HTML5] Accessibility question
On 1 Apr 2008, at 9:00 am, Benjamin Hawkes-Lewis wrote: Hmm … http://www.w3.org/TR/wai-aria/#hidden seems to be specified as equivalent to visibility: hidden, a property that theoretically shouldn't affect speech rendering but does (accidentally) hide content from screen readers. It doesn't say anything about display: none;. I know that everyone already knows this, but I think a reminder might be timely: Be careful not to confuse screen readers, who's job it is to read what is displayed on the screen, with a voice browser, who's job it is to parse a HTML document into a DOM tree and apply media-less and aural CSS (and potentially never display anything on screen). visibility: hidden and display: none should both hide content from screen readers. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] [HTML5] Accessibility question
Nicholas Shanks wrote: On 1 Apr 2008, at 9:00 am, Benjamin Hawkes-Lewis wrote: Hmm … http://www.w3.org/TR/wai-aria/#hidden seems to be specified as equivalent to visibility: hidden, a property that theoretically shouldn't affect speech rendering but does (accidentally) hide content from screen readers. It doesn't say anything about display: none;. I know that everyone already knows this, but I think a reminder might be timely: Be careful not to confuse screen readers, who's job it is to read what is displayed on the screen, That's something of a simplification; the word read in particular is as likely to confuse as to clarify (yes, the name doesn't help here). It's the job of a screen reader to provide people with severe visual impairments with access to a computer system. That regularly entails more than reading what is displayed on screen, including also things like querying document or application models and constructing further internal models on top of those (for example, to produce a list of links, or extract hidden help text, or construct a text-stream view of a webpage in a virtual buffer). http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_withoutvisinfosheet.hcsp http://en.wikipedia.org/wiki/Screen_reader A program whose 'job it is to read what is displayed on the screen' works better as a description of simpler text-to-speech programs (which also exist). with a voice browser, who's job it is to parse a HTML document into a DOM tree and apply media-less and aural CSS (and potentially never display anything on screen). I agree it's important to distinguish screen readers from voice browsers. Two example differences from an end-user perspective: 1. Screen readers typically provide access to an entire system rather than simply being a self-voicing application for browsing the web or an application that happens to include speech output. 2. Screen readers also typically output braille. :) visibility: hidden and display: none should both hide content from screen readers. I don't think it's that clear-cut in theory or practice. Screen readers don't map directly to the speech/aural or braille media types. But they don't map directly to the screen media type either. They involve different modes of access, not just a different media type. See also one slice of the complicated story at: Does JAWS support cascading style sheets (CSS)? http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=1165 -- Benjamin Hawkes-Lewis
Re: [whatwg] [HTML5] Accessibility question
On 1 Apr 2008, at 10:14 am, Benjamin Hawkes-Lewis wrote: Nicholas Shanks wrote: I know that everyone already knows this, but I think a reminder might be timely: Be careful not to confuse screen readers, who's job it is to read what is displayed on the screen, That's something of a simplification; the word read in particular is as likely to confuse as to clarify (yes, the name doesn't help here). It's the job of a screen reader to provide people with severe visual impairments with access to a computer system. Well i would disagree: that's the job of an accessibility suite for the blind. A screen reader is just one component of such a suite. That regularly entails more than reading what is displayed on screen, including also things like querying document or application models and constructing further internal models on top of those (for example, to produce a list of links, or extract hidden help text, or construct a text-stream view of a webpage in a virtual buffer). http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_withoutvisinfosheet.hcsp http://en.wikipedia.org/wiki/Screen_reader A program whose 'job it is to read what is displayed on the screen' works better as a description of simpler text-to-speech programs (which also exist). Am at work and haven't time to read these at the moment. Will do so this evening. with a voice browser, who's job it is to parse a HTML document into a DOM tree and apply media-less and aural CSS (and potentially never display anything on screen). I agree it's important to distinguish screen readers from voice browsers. Two example differences from an end-user perspective: 1. Screen readers typically provide access to an entire system rather than simply being a self-voicing application for browsing the web or an application that happens to include speech output. 2. Screen readers also typically output braille. :) Then I would call such software a screen reader + braille renderer + hacks around in your OS program doing nasty things program. I don't think a pure screen reader should know anything about CSS or DOM or an application's internals. visibility: hidden and display: none should both hide content from screen readers. I don't think it's that clear-cut in theory or practice. Screen readers don't map directly to the speech/aural or braille media types. But they don't map directly to the screen media type either. They involve different modes of access, not just a different media type. See also one slice of the complicated story at: Does JAWS support cascading style sheets (CSS)? http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=1165 Besides my opinion that JAWS is probably the worst example of an accessibility program that exists, it is far from being just a screen reader. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
[whatwg] Semantic markup for buzzwords
This is a proposal for semantic markup in HTML5. Problem statement: Modern web pages, especially those written for marketing purposes, often include so-called buzzwords, or trend-leveraging verbal tokens. Markup for them is needed both to achieve distinct visual rendering and to emphasize them for search engines. Despite the need for specialized semantic markup, currently no such markup exists, and authors use ad-hoc presentational markup for buzzwords. Proposed solution: Redefine the existing deprecated presentational element B to mean a buzzword. Keep existing default style (font-weight: bold) associated with it. With such formatting, buzzwords will visually stand out on the page, allowing the reader, such as a prospective VC evaluating an IT project proposal, to briefly skim through a web page picking out only buzzwords. Advantages: * The solution is backward compatible with existing browsers which already implement distinct rendering for B. * The practice of using B to mark up buzzwords is already widely adopted. * Some search engines rank words marked up with B higher than the rest of the text. * B is a nice single-letter tag name that would be sad to waste as an obsolete element. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://my.opera.com/feldgendler/
Re: [whatwg] [HTML5] Accessibility question
Nicholas Shanks wrote: Then I would call such software a screen reader + braille renderer + hacks around in your OS program doing nasty things program. I don't think a pure screen reader should know anything about CSS or DOM or an application's internals. Well, you could do that, but then you're just redefining the term screen reader to apply to non-existent, theoretical, and potentially rather useless software rather than the useful software to which the term is usually applied and that allows my blind colleagues to do their job. Web browsers don't just browse the web; word processors don't just process words; screen readers don't just read the screen; HTML5 doesn't just provide a markup language for documents. Language purism of this sort is a distraction from solving real problems. -- Benjamin Hawkes-Lewis
Re: [whatwg] Video
Silvia Pfeiffer wrote: The current standard for publishing media on the Web, in particular consumer media, is Adobe Flash. This is the case not because of the codecs inside Adobe Flash but because sites such as YouTube enable consumers to publish media without having to worry about license fees and patents, as well as technical issues. The enabler here is the embed tag. And sites such as YouTube build on Adove Flash because it's the only currently viable cross-platform media technology that runs in most browsers. :-( -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Semantic markup for buzzwords
On Tue, 01 Apr 2008 18:08:20 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: I believe the current definition of the B element allows for such use: http://www.whatwg.org/specs/web-apps/current-work/#the-b The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened. This describes b as a presentational element, but my proposal makes it semantic. On Tue, 01 Apr 2008 18:05:44 +0200, Brian Kardell [EMAIL PROTECTED] wrote: Can you please explain precisely how this would differ from strong which really should work exactly as you described? Is it really mostly just the fact that some search engines don't accurately respect strong as being the essential equivalent of b? If so, then I would like to suggest that this might not be the best solution, and that suggesting some alternative tag for semantics isn't probably going to help solve this problem in any meaningful way since the recommendations that we have around now have been available for search engines to figure out and implement for longer than some of the engines themselves. Could you not achieve what you are looking for with meta tags or some alternative means? Using a different tag name would suffer from the chicken-and-egg probem, and the advantage of b is that it's already widely used for exactly the purpose proposed. Just my 2 cents for what they are worth. Also - it is very possible that I don't understand, if so could you expand? Taking into account the very special date on which this discussion is happening should clarify matters. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://my.opera.com/feldgendler/
Re: [whatwg] Semantic markup for buzzwords
On 01/04/2008, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Tue, 01 Apr 2008 18:08:20 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: Just my 2 cents for what they are worth. Also - it is very possible that I don't understand, if so could you expand? Taking into account the very special date on which this discussion is happening should clarify matters. I thought that was the one advocating H.264. - d.
Re: [whatwg] Video
Robert J Crisler wrote: From my perspective, and for what it's worth, I doubt that the ideals of the W3C as expressed in 3.12.7.1 http://3.12.7.1 would result in a situation that would be superior to simply letting the international standards body for audio and video codecs deal with these technological areas. Your plan would, at least, prevent the standard codec being supported on Free operating systems. Meeting 3.12.7.1 as it stands would not prevent this. Therefore, it would be a superior situation. Who wins and who loses? Web and new media developers win by having a streamlined workflow and one expectation for video and audio standards support in browsers. Users win by not having to worry about whether or not they have the right plug-in for Site A or Site B. Well, the users who can get a licence win. Other users lose. The issue of a small licensing fee didn't stop MPEG 1 Part 3 from becoming the ubiquitous world standard for audio. It isn't going to stop MPEG-4 AAC from supplanting it, and it hasn't stopped MPEG-2 and AVC from being the standard for HD codecs. Insisting on purity in these matters while the world moves on strikes me as just a bit quixotic. It's as much a question of practicality as purity. How do you track and collect per-copy royalties for an OS which can be mirrored and redistributed by anyone? Gerv
Re: [whatwg] Video
On 01/04/2008, Gervase Markham [EMAIL PROTECTED] wrote: Robert J Crisler wrote: From my perspective, and for what it's worth, I doubt that the ideals of the W3C as expressed in 3.12.7.1 http://3.12.7.1 would result in a situation that would be superior to simply letting the international standards body for audio and video codecs deal with these technological areas. Your plan would, at least, prevent the standard codec being supported on Free operating systems. Meeting 3.12.7.1 as it stands would not prevent this. Therefore, it would be a superior situation. The actual solution is a large amount of compelling content in Theora or similar. Wikimedia is working on this, though we're presently hampered by a severe lack of money for infrastructure and are unlikely to have enough in time for FF3/Webkit/HTML5. - d.
Re: [whatwg] Semantic markup for buzzwords
On Apr 1, 2008, at 2:48 AM, Alexey Feldgendler wrote: This is a proposal for semantic markup in HTML5. Problem statement: Modern web pages, especially those written for marketing purposes, often include so-called buzzwords, or trend-leveraging verbal tokens. Markup for them is needed both to achieve distinct visual rendering and to emphasize them for search engines. Despite the need for specialized semantic markup, currently no such markup exists, and authors use ad-hoc presentational markup for buzzwords. Proposed solution: Redefine the existing deprecated presentational element B to mean a buzzword. Keep existing default style (font-weight: bold) associated with it. With such formatting, buzzwords will visually stand out on the page, allowing the reader, such as a prospective VC evaluating an IT project proposal, to briefly skim through a web page picking out only buzzwords. Advantages: * The solution is backward compatible with existing browsers which already implement distinct rendering for B. * The practice of using B to mark up buzzwords is already widely adopted. * Some search engines rank words marked up with B higher than the rest of the text. * B is a nice single-letter tag name that would be sad to waste as an obsolete element. I believe the current definition of the B element allows for such use: http://www.whatwg.org/specs/web-apps/current-work/#the-b The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened. Regards, Maciej
