[whatwg] Media Accessibility Checklist, please review and comment (relates to timed tracks discussion)
The following document has recently been made available for review: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist It is the product of quite a lot of discussion and work, by a number of people, toward the goal of identifying specific needs of users with disabilities for alternative access to web-based media. It would be worthwhile to have wide review of that document to make sure it actually accomplishes that goal. So if you can make time to review it, comments and questions on it are welcome anywhere; for example, as a reply to this message, or as entries on the related Talk page here: http://www.w3.org/WAI/PF/HTML/wiki/Talk:Media_Accessibility_Checklist Thanks, --Mike -- Michael(tm) Smith http://people.w3.org/mike
Re: [whatwg] Media Accessibility Checklist, please review and comment (relates to timed tracks discussion)
Michael(tm) Smith m...@w3.org, 2010-09-14 19:26 +0900: So if you can make time to review it, comments and questions on it are welcome anywhere; for example, as a reply to this message, or as entries on the related Talk page here: http://www.w3.org/WAI/PF/HTML/wiki/Talk:Media_Accessibility_Checklist It was brought to my attention that the above page is editable only by certain people in the W3C user DB. So, I have made a copy of the associated page, with its own Talk page: http://www.w3.org/html/wiki/Talk:MediaAccessibilityChecklist You will need to set up a W3C user account in order to authenticate to edit that -- but anybody is welcome to open such an account. That said, as I mentioned before, comments here are welcome also. --Mike -- Michael(tm) Smith http://people.w3.org/mike
Re: [whatwg] [HTML5] Accessibility question
On Sat, 22 Mar 2008, Nicholas C. Zakas wrote: Apologies for not replying sooner, I've been struck with a bit of the flu. The problem I'm trying to solve is the case where you need descriptive text for screen readers but that text is not necessary for sighted users. For example, our accessibility guidelines at Yahoo! say that every unordered list (ul) should be preceeded by a header that describes its use. The header may say something like Page options or Available styles and we use CSS tricks (text-indent: -1px;) to hide these headings from display while allowing screen readers to read them. To sighted users, the meaning of the list is apparent because they can see the visual treatments we've applied whereas blind users would just hear a list read out of context. Another example is for buttons that make use of sprites. Something is implemented as a link but with a background image that's part of a sprite. The link needs to have descriptive text for screen readers but the text is unnecessary for sighted users as they can see the image. For example: a href=# class=closespanClose/span/a For things like this, I usually end up using the same CSS trick mentioned above to move the Close text out of the way. Just looking at the HTML, it's not apparent that Close is not intended to seen. Whereas the following clears it up: a href=# class=closespan noviewClose/span/a Now I know from looking at the source code that Close is clearly not intended to be seen. This seems like a CSS problem. The text is only inapplicable because of the CSS, right? If the CSS wasn't applied, then even on a screen, the user would need the titles or button text you've described. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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
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] [HTML5] Accessibility question
On Mar 31, 2008, at 08:10, Nicholas C. Zakas wrote: @irrelevant is virtually indistinguishable from setting content to display: none. My point in bringing up accessibility with a possible attribute or element is to figure out where the lines between HTML and CSS are, as it appears HTML 5 has muddied the water. As I stated earlier on this list, if something is truly irrelevant, then it's not included in the page. Something that's on the page and hidden is relevant, just perhaps not at the current time, which led to the suggestion on this list to rename the attribute ignore. I agree that the semantic fig leaf is confusing. It means hidden (from all interaction modes). 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 still feel like it's a good idea to have an optional attribute on each element that indicates the element's content should not be ignored by screen readers regardless of the style applied. Perhaps this could be better handled by an ARIA role... 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.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] [HTML5] Accessibility question
So given all of this, is it reasonable to expect HTML 5 to provide something for this use case? Perhaps my suggestions of @noview introduces incorrect semantics, perhaps something along the lines of @important to indicate content is important regardless of style (and so screen readers should not ignore it)? -Nicholas - Original Message From: Henri Sivonen [EMAIL PROTECTED] To: Nicholas C.Zakas [EMAIL PROTECTED] Cc: Benjamin Hawkes-Lewis [EMAIL PROTECTED]; whatwg List [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED] Sent: Monday, March 31, 2008 3:46:46 AM Subject: Re: [whatwg] [HTML5] Accessibility question On Mar 31, 2008, at 08:10, Nicholas C. Zakas wrote: @irrelevant is virtually indistinguishable from setting content to display: none. My point in bringing up accessibility with a possible attribute or element is to figure out where the lines between HTML and CSS are, as it appears HTML 5 has muddied the water. As I stated earlier on this list, if something is truly irrelevant, then it's not included in the page. Something that's on the page and hidden is relevant, just perhaps not at the current time, which led to the suggestion on this list to rename the attribute ignore. I agree that the semantic fig leaf is confusing. It means hidden (from all interaction modes). 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 still feel like it's a good idea to have an optional attribute on each element that indicates the element's content should not be ignored by screen readers regardless of the style applied. Perhaps this could be better handled by an ARIA role... 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.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com
Re: [whatwg] [HTML5] Accessibility question
@irrelevant is virtually indistinguishable from setting content to display:
none. My point in bringing up accessibility with a possible attribute or
element is to figure out where the lines between HTML and CSS are, as it
appears HTML 5 has muddied the water. As I stated earlier on this list, if
something is truly irrelevant, then it's not included in the page. Something
that's on the page and hidden is relevant, just perhaps not at the current
time, which led to the suggestion on this list to rename the attribute
ignore.
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.
I still feel like it's a good idea to have an optional attribute on each
element that indicates the element's content should not be ignored by screen
readers regardless of the style applied. Perhaps this could be better handled
by an ARIA role...
-Nicholas
- Original Message
From: Benjamin Hawkes-Lewis [EMAIL PROTECTED]
To: Nicholas C. Zakas [EMAIL PROTECTED]
Cc: whatwg List [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 12:27:37 PM
Subject: Re: [whatwg] [HTML5] Accessibility question
Nicholas C. Zakas wrote:
The first use case is now handled in HTML 5 via @irrelevant.
I don't think it is, actually:
http://www.w3.org/html/wg/html5/#the-irrelevant
Additional content is not irrelevant; it's helpful sometimes and
superfluous at other times.
The draft spec says User agents should not render elements that have
the irrelevant attribute specified. This is incompatible with what I'm
suggesting, which is that user agents might want to render additional
content when it is helpful and ignore it when it is superfluous.
The intention of the draft seems to be that @irrelevant should be
manipulated by scripting. That too is incompatible with what I'm
suggesting, where UA logic and user actions decide whether to render
additional content or not (a bit like @title).hey
We currently now use display: none or
visibility: hidden to hide content that isn't necessary for users at
that time, which is the same purpose as @irrelevant (from previous
discussions).
Display: none; or visibility: hidden; affect only the suggested
presentation of information; @irrelevant changes the semantics.
It's true that developers sometimes try to use display: none; and
visibility: hidden; like @irrelevant could be used; I think that's
(often) unwise because they are such brittle tweaks in the wrong layer.
I'm very familiar with defining separate CSS classes for moving content
offscreen, and it seems like a big hack to me.
It is very hacky, agreed.
It also seems that this
is a common enough use case that it merits further investigation.
Yep.
Perhaps the greater
question is whether or all showing/hiding of content is really a CSS
issue or if there are some that use cases that do belong in HTML.
Sometimes content's superfluity is itself dependent on the
presentational skin. For example, if CSS radically distinguishes a
navigation area from surrounding content, having a Navigation header
might become superfluous. In such cases, it makes more sense to use the
off-screen hack or some better (future) CSS technique, e.g.:
nav h1:out-of-context {
display: block;
}
But ideally a suggested presentational skin should not be used to try
and designate content to be superflous when its superfluity depends on
browsing context not the skin itself, for example when part of a link's
text is superfluous if you're going through the document in order.
--
Benjamin Hawkes-Lewis
No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo!
users and friends.
http://tc.deals.yahoo.com/tc/blockbuster/text1.com
Re: [whatwg] [HTML5] Accessibility question
Nicholas C. Zakas wrote: The problem I'm trying to solve is the case where you need descriptive text for screen readers but that text is not necessary for sighted users. Hmm. I think we need to take a step back and define this problem more carefully. Arguably, screenreader users are sometimes hindered by descriptive text as much as helped. Moreover, they are by no means the only group who benefit from text descriptions and equivalents. Other users who might benefit include: 1. Users of non-screen media types (e.g. printing pages or using voice browsers or console browsers). 2. Users of graphical browsers who disable images, either for accessibility reasons or because of low bandwidth. 3. Users of graphical browsers who enforce their own colors and backgrounds (a common option). 4. Users of graphical browsers who turn off author stylesheets or apply user stylesheets. 5. Users of graphical browsers using more-or-less atypical navigation strategies (e.g. links lists, document maps, typeahead find, reading snippets in a search engine). I suspect there are actually at least two different use-cases here: Use-case A: Decontextualized navigation (where parts of the page are shown for navigational purposes (e.g. lists of elements by type, potentially reordered, or snippets in a search result) and nonsequential browsing (e.g. jumping to the next link or list element). Ideally, tools should be able to infer relationships between different bits of presented content, and use this to provide essential context. Examples include headers for data cells; long descriptions for images; headings for sections; definitions for terms; labels for buttons. But where relationships either cannot be programatically inferred or are hard to express in a user interface, publishers want to support decontextualized navigation and nonsequential browsing with targeted, additional content that provides the minimum requisite context for users to understand where they're going and where they've arrived. Use-case B: Separation of content from graphical enhancements. Examples include graphical mastheads, icons, and buttons that vary between themes (i.e. alternate stylesheets). Can anyone think of any others? I would argue the ideal behavior of a screenreader is not the same in these different use-cases. With use-case A, you only need the additional content rendered when using decontextualized navigation or engaged in non-sequential browsing. For example, let's say you have five promotion modules each with markup along the lines of: div class=module promotion h2Bunnies/h2 img alt=A well-fed white bunny demolishes a carrot with relish. src=bunny.jpg pBunnies are full of intrinsic win, being as they are floppy-eared, fluffy, and cute…/p a href=http://example.com/more-about-bunnies.html;Read more/a /div If a consuming agent abstracts the links out into a list of all links in the document, then users have no way of knowing what the five Read more links refer to. It would help if some extra context was provided, for example: Read more about bunnies. However, if you're reading linearly through content and have just read Bunnies are full of win, being as they are floppy-eared, fluffy, and cute…, then the addition of about bunnies would be superfluous verbiage reducing accessibility by slowing you down. However, with use-case B, you would always want to hear or braille the text rendering of the content, whether browsing in or out of context. * Solutions for use-case A: decontextualized navigation and nonsequential browsing * CSS display: none; is still often used to hide context-providing content, but it doesn't work in practice because: 1. Publishers often apply display: none; to all media types explicitly under the illusion that display refers only to visual rendering. 2. Popular browsers default to applying styles to all media types not screen, but publishers don't realize that (the HTML 4.01 specification says the default type is screen). 3. display: none; is often used to hide content that is unhidden through scripted behavior, without any thought about what happens in other media types. Rendering content with display: none; could easily hinder accessibility in such cases. 4. Popular screenreaders work from the screen media type and generally don't read content hidden with display: none;. 5. The problem we're trying to solve does not arise from different visibility being appropriate to different media types, but from different visibility being appropriate to different browsing strategies. Another common technique is to annotate content (e.g. lists and links) with context using with the TITLE attribute. But TITLE is overloaded with uses (abbreviation expansions, tooltip help, keyword spamming) and has its own accessibility problems: http://www.w3.org/TR/WCAG20-CSS-TECHS/H33.html
Re: [whatwg] [HTML5] Accessibility question
Apologies for not replying sooner, I've been struck with a bit of the flu. The problem I'm trying to solve is the case where you need descriptive text for screen readers but that text is not necessary for sighted users. For example, our accessibility guidelines at Yahoo! say that every unordered list (ul) should be preceeded by a header that describes its use. The header may say something like Page options or Available styles and we use CSS tricks (text-indent: -1px;) to hide these headings from display while allowing screen readers to read them. To sighted users, the meaning of the list is apparent because they can see the visual treatments we've applied whereas blind users would just hear a list read out of context. Another example is for buttons that make use of sprites. Something is implemented as a link but with a background image that's part of a sprite. The link needs to have descriptive text for screen readers but the text is unnecessary for sighted users as they can see the image. For example: a href=# class=closespanClose/span/a For things like this, I usually end up using the same CSS trick mentioned above to move the Close text out of the way. Just looking at the HTML, it's not apparent that Close is not intended to seen. Whereas the following clears it up: a href=# class=closespan noviewClose/span/a Now I know from looking at the source code that Close is clearly not intended to be seen. -Nicholas - Original Message From: Ian Hickson [EMAIL PROTECTED] To: Nicholas C. Zakas [EMAIL PROTECTED] Cc: whatwg List [EMAIL PROTECTED] Sent: Sunday, March 16, 2008 6:36:17 PM Subject: Re: [whatwg] [HTML5] Accessibility question On Sun, 16 Mar 2008, Nicholas C. Zakas wrote: I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Wouldn't hiding content from sighted viewers hurt accessibility for sighted viewers? Could you elaborate more on what problem you are trying to solve? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [whatwg] [HTML5] Accessibility question
I don't think this is a CSS issue, it follows along the lines of noscript for hiding content in some cases or @irrelevant (hopefully renamed to @ignore :) ) hiding content in others. CSS generated content will be displayed on the screen just as regular content is, which is the very problem I'm proposing needs to be solved. -Nicholas - Original Message From: Sam Kuper [EMAIL PROTECTED] To: Ian Hickson [EMAIL PROTECTED] Cc: Nicholas C. Zakas [EMAIL PROTECTED]; whatwg List [EMAIL PROTECTED] Sent: Monday, March 17, 2008 7:19:48 PM Subject: Re: [whatwg] [HTML5] Accessibility question On 17/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: That seems more like a CSS issue. I now think so too. Simon Pieters made the point that CSS3 can solve this problem. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] [HTML5] Accessibility question - SSML
Well I already do include embedded SSML on my website. I also submitted some XSLT to transform XHTML into a full SSML document which can be piped to speech synthesisers like Swift, that understand the format. http://bugs.webkit.org/show_bug.cgi?id=10363 On 18 Mar 2008, at 10:23 pm, Keryx Web wrote: Benjamin Hawkes-Lewis skrev: I think it's a mistake to assume a accessible or screen-reader- friendly view should be non-interactive. In so far as this is true at all, it's largely a result of web interactivity depending on non-standard widgets. AFAICT, this is one of the problems HTML5 tries to solve. Hear, hear! We also need to work with screen readers and browser developers so that that CSS media rules actually start to be applied. And Webkit should join the ARIA party! A thought (an just a thought), however, that might be worth investigating is if SSML could be embedded into HTML, using similar principles as is being considered for SVG. Lars Gunther — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] [HTML5] Accessibility question - SSML
Benjamin Hawkes-Lewis skrev: I think it's a mistake to assume a accessible or screen-reader-friendly view should be non-interactive. In so far as this is true at all, it's largely a result of web interactivity depending on non-standard widgets. AFAICT, this is one of the problems HTML5 tries to solve. Hear, hear! We also need to work with screen readers and browser developers so that that CSS media rules actually start to be applied. And Webkit should join the ARIA party! A thought (an just a thought), however, that might be worth investigating is if SSML could be embedded into HTML, using similar principles as is being considered for SVG. Lars Gunther
Re: [whatwg] [HTML5] Accessibility question
On 17/03/2008, Nicholas C. Zakas [EMAIL PROTECTED] wrote: I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Is there an example of something which you think should be seen by screen readers but not by sighted users? Also, isn't this doing something similar to what display : none does in CSS (browsers won't render this content, but I presume screen readers will still read it out)? Paul -- Paul Waring http://www.pwaring.com
Re: [whatwg] [HTML5] Accessibility question
Paul is right, you can just use:
@media (screen, print, handheld) { .foo { display: none; } }
Since no screenreader i know of supports aural media you can't yet do
it the other way around (default to none and show for aural)
On 17 Mar 2008, at 2:08 am, Nicholas C. Zakas wrote:
I know the topic has come up a few times, but I'm still wondering if
HTML 5 should provide some sort of logic around content that should
not be displayed by browsers but should be read by screen readers.
Perhaps a noview boolean attribute on each element could be used
to tell UAs not to render the content but to report it to screen
readers? Or maybe a noview/ element could be used to surround
content that shouldn't be displayed but should be accessible to
screen readers?
Any thoughts?
-Nicholas
Looking for last minute shopping deals? Find them fast with Yahoo!
Search.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
Re: [whatwg] [HTML5] Accessibility question
I think the question is justified. It's the same as with the noscript
tag. Depending on the javascript support, you'll see EITHER the
contents of the script tag OR the contents of the noscript tag.
Imagine you've got a highly interactive ajax application with drag and
drop and everything else. I would like to place this multimedia
(where multimedia doesn't necessary mean audio/video) content into a
view tag and a more accessible version into a noview tag.
So it's not only about hiding extra accessibilty information from the
screen, but also about hiding interactvie/... information from the
screenreader/...
Zitat von Nicholas Shanks [EMAIL PROTECTED]:
Paul is right, you can just use:
@media (screen, print, handheld) { .foo { display: none; } }
Since no screenreader i know of supports aural media you can't yet do
it the other way around (default to none and show for aural)
On 17 Mar 2008, at 2:08 am, Nicholas C. Zakas wrote:
I know the topic has come up a few times, but I'm still wondering
if HTML 5 should provide some sort of logic around content that
should not be displayed by browsers but should be read by screen
readers. Perhaps a noview boolean attribute on each element
could be used to tell UAs not to render the content but to report
it to screen readers? Or maybe a noview/ element could be used
to surround content that shouldn't be displayed but should be
accessible to screen readers?
Any thoughts?
-Nicholas
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
? Nicholas Shanks.
Re: [whatwg] [HTML5] Accessibility question
On 16/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: Could you elaborate more on what problem you are trying to solve? I wonder if this http://www.alistapart.com/articles/fir/ is one of the problems to do with content for sighted/unsighted viewers it might be nice to have a good solution to in HTML5?
Re: [whatwg] [HTML5] Accessibility question
On Mon, 17 Mar 2008 16:46:45 +0100, Paul Waring [EMAIL PROTECTED] wrote: On 17/03/2008, Nicholas C. Zakas [EMAIL PROTECTED] wrote: I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Is there an example of something which you think should be seen by screen readers but not by sighted users? Also, isn't this doing something similar to what display : none does in CSS (browsers won't render this content, but I presume screen readers will still read it out)? Bad assumption - they don't read it out. They read what is put on the screen. (Well, sort of - what they actually do is parse the DOM themselves quite often, as well). One reason for this is that a lot of authors put stuff there for screen reader users that just adds to the clutter on their page - an easy mistake if you're not used to what screen readers are actually like to work with. Designers put things (including useful things) on pages for screen reader users, and then hide them in various ways - things like [D] links, the skip to content links, alternatives for images that are more than just a text string so can't go in as alt, etc. I don't like the use case, but it is pretty common and if you want to be compatible with the real web we should have a way to deal with it. At the moment the most commonly successful technique is positioning things offscreen, but that's not a great solution either. In my ideal world, people would actually implement the aural style, but I think we are the biggest implementation of that and we only do it on windows for the voice plugin :( cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] [HTML5] Accessibility question
On Mon, 17 Mar 2008 18:17:19 +0100, Sam Kuper [EMAIL PROTECTED]
wrote:
On 16/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
Could you elaborate more on what problem you are trying to solve?
I wonder if this http://www.alistapart.com/articles/fir/ is one of the
problems to do with content for sighted/unsighted viewers it might be
nice
to have a good solution to in HTML5?
I think this is more of a problem with CSS, and one that is, AFAICT,
solved with CSS3 generated content (which is implemented in Opera,
although I have not tested it in Opera in combination with a screen
reader):
h1 { content:url(foo.png) }
--
Simon Pieters
Opera Software
Re: [whatwg] [HTML5] Accessibility question
On 17/03/2008, Charles McCathieNevile [EMAIL PROTECTED] wrote: Bad assumption - they don't read it out. They read what is put on the screen. (Well, sort of - what they actually do is parse the DOM themselves quite often, as well). One reason for this is that a lot of authors put stuff there for screen reader users that just adds to the clutter on their page - an easy mistake if you're not used to what screen readers are actually like to work with. Ah, it would appear that screen readers have got a bit more advanced since the last time I looked into them (which admittedly was some time ago) - back then I think many of them still read out 'hidden' text. In my ideal world, people would actually implement the aural style, but I think we are the biggest implementation of that and we only do it on windows for the voice plugin :( If there is already something which does this then, is there really a need for a noview element? Paul -- Paul Waring http://www.pwaring.com
Re: [whatwg] [HTML5] Accessibility question
On Mar 17, 2008, at 1:05 PM, Simon Pieters wrote:
On Mon, 17 Mar 2008 18:17:19 +0100, Sam Kuper
[EMAIL PROTECTED] wrote:
On 16/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
Could you elaborate more on what problem you are trying to solve?
I wonder if this http://www.alistapart.com/articles/fir/ is one
of the
problems to do with content for sighted/unsighted viewers it might
be nice
to have a good solution to in HTML5?
I think this is more of a problem with CSS, and one that is, AFAICT,
solved with CSS3 generated content (which is implemented in Opera,
although I have not tested it in Opera in combination with a screen
reader):
h1 { content:url(foo.png) }
Safari/WebKit also supports this construct.
Regards,
Maciej
Re: [whatwg] [HTML5] Accessibility question
Dave Oneal wrote: I think the question is justified. It's the same as with the noscript tag. Depending on the javascript support, you'll see EITHER the contents of the script tag OR the contents of the noscript tag. Imagine you've got a highly interactive ajax application with drag and drop and everything else. I would like to place this multimedia (where multimedia doesn't necessary mean audio/video) content into a view tag and a more accessible version into a noview tag. So it's not only about hiding extra accessibilty information from the screen, but also about hiding interactvie/... information from the screenreader/... I think it's a mistake to assume a accessible or screen-reader-friendly view should be non-interactive. In so far as this is true at all, it's largely a result of web interactivity depending on non-standard widgets. AFAICT, this is one of the problems HTML5 tries to solve. -- Benjamin Hawkes-Lewis
Re: [whatwg] [HTML5] Accessibility question
On Mon, 17 Mar 2008, Sam Kuper wrote: On 16/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: Could you elaborate more on what problem you are trying to solve? I wonder if this http://www.alistapart.com/articles/fir/ is one of the problems to do with content for sighted/unsighted viewers it might be nice to have a good solution to in HTML5? That seems more like a CSS issue. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [HTML5] Accessibility question
On Mon, 17 Mar 2008 20:07:52 -, Paul Waring [EMAIL PROTECTED] wrote: On 17/03/2008, Charles McCathieNevile [EMAIL PROTECTED] wrote: Bad assumption - they don't read it out. They read what is put on the screen. (Well, sort of - what they actually do is parse the DOM themselves quite often, as well). One reason for this is that a lot of authors put stuff there for screen reader users that just adds to the clutter on their page - an easy mistake if you're not used to what screen readers are actually like to work with. Ah, it would appear that screen readers have got a bit more advanced since the last time I looked into them (which admittedly was some time ago) - back then I think many of them still read out 'hidden' text. Must have been a very long time ago. They generally haven't done that. In my ideal world, people would actually implement the aural style, but I think we are the biggest implementation of that and we only do it on windows for the voice plugin :( If there is already something which does this then, is there really a need for a noview element? I don't think introducing a new element will change anything, it will just complicate the things that we should be focusing attention on, so I don't think there is any need for such an element. cheers chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] [HTML5] Accessibility question
On 17/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: That seems more like a CSS issue. I now think so too. Simon Pieters made the point that CSS3 can solve this problem.
Re: [whatwg] [HTML5] Accessibility question
On Mon, 17 Mar 2008 20:05:22 -, Simon Pieters [EMAIL PROTECTED] wrote:
On Mon, 17 Mar 2008 18:17:19 +0100, Sam Kuper [EMAIL PROTECTED]
wrote:
On 16/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
Could you elaborate more on what problem you are trying to solve?
I wonder if this http://www.alistapart.com/articles/fir/ is one of the
problems to do with content for sighted/unsighted viewers it might be
nice
to have a good solution to in HTML5?
I think this is more of a problem with CSS, and one that is, AFAICT,
solved with CSS3 generated content (which is implemented in Opera,
although I have not tested it in Opera in combination with a screen
reader):
h1 { content:url(foo.png) }
It doesn't work with a screen reader in either Safari or Opera using
VoiceOver - and I wouldn't expect it to until differentiating media types
is reliably implemented. So this seems like an approach to avoid - the use
of off-screen positioning is less harmful (if still not that great). If
anyone wants a test case, let me know - I would expect that in Windows no
screen reader will read the content either, but don't have a windows
machine to test (although I need one - at least I have a handful of
windows screen readers).
cheers
Chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
[whatwg] [HTML5] Accessibility question
I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Any thoughts? -Nicholas Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [whatwg] [HTML5] Accessibility question
On Sun, 16 Mar 2008, Nicholas C. Zakas wrote: I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Wouldn't hiding content from sighted viewers hurt accessibility for sighted viewers? Could you elaborate more on what problem you are trying to solve? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] On accessibility
Le 14 juin 2006 à 21:09, Lachlan Hunt a écrit : If implementations can be modified so that accesskeys do not interfere with existing shortcut keys, then that's great. Perhaps they could offer a kind of web-apps mode where all Alt+[key] combinations are safe to be used by the web page, and then another mode where they retain their normal browser functions. But until something like that happens and proves successful, accesskeys should not be retained. I'd like to point out that accesskeys are working very well on the Mac. Application commands are issued using the Command key and most browsers bind accesskeys to the minimally-used Control key. Accesskeys do not conflict with other system and application shortcuts unless the user defines his own conflicting shortcuts in the system preferences. It would be sad to see accesskeys disappear just because they are hard to implement elsewhere. But I acknowledge most other computers don't have a spare key which can be used for that. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] On accessibility
On Jun 15, 2006, at 06:29, Alexey Feldgendler wrote: Here is what I think should be standardized: a user agent which supports accesskeys MUST provide an uniform method of invoking any accesskey which is a letter or a digit. Do you mean 0-9 and a-z or any Unicode digit or letter? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] On accessibility
On Thu, 15 Jun 2006 16:29:35 +0700, Henri Sivonen [EMAIL PROTECTED] wrote: Here is what I think should be standardized: a user agent which supports accesskeys MUST provide an uniform method of invoking any accesskey which is a letter or a digit. Do you mean 0-9 and a-z or any Unicode digit or letter? This is details which, of course, should be discussed. I think that requiring availability of 0-9 and A-Z is all that we can ask a compliant UA of. Because not every environment is capable of input in every language, we can't require that of an UA. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] On accessibility
At 10:29 +0700 UTC, on 2006-06-15, Alexey Feldgendler wrote: [...] Here is what I think should be standardized: a user agent which supports accesskeys MUST provide an uniform method of invoking any accesskey which is a letter or a digit. This method should be designed so that the UA's own key bindings never conflict with the accesskeys. FWIW, IMO this is not the terrain of a HTML spec. That aside, it seems to me that a browser that allows such keyboard-shortcut conflicts to occur is so obviously broken that I don't even understand why it needs to be discussed at all, let alone /here/. *If* you want to go there, the effort should be much broader: you should then also state that browsers must by default indicate the existence of a TITLE attribute; that browsers must indicate when their ESP engine has kicked in so the user knows that what is rendered is at best an educated guess; etc. It might very well be useful to have such a spec -- something along the lines of the GNKSA[*]. It might certainly be helpful to users to have a comparison chart available, maybe with a scoring per browser or even some sort of certification. But I don't see why such requirements should be spelled out in a HTML spec. [*] http://www.newsreaders.com/gnksa/ -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
[whatwg] On accessibility
Hi, I've spoken to a person who is blind about HTML5 and accessibility. I thought I'd send some of his thoughts to the list. He is in favor of the new nav and article elements indicating the navigation section of the page and what is the main content: yeah that'd be excellent, if screen readers would pick up on this somehow. because really my main goal when I get to the front page of a web site, if I've not been there before, is to get to the main content and see what that site's about, what's on that site, etc. My second goal is then to get to the navigation to find a section I'd like to navigate to. He says that HTML5 shouldn't drop the longdesc attribute, because it is useful for people using screen readers. longdesc is a long description, which is what you're wanting to give. alt is alternative text, which is just to give me a basic idea of what's there. i don't want to read a big paragraph for an image unless I really wan to know what's there. He also says that he accesskeys shouldn't be dropped. I love accesskeys, despite anything bad people have said about them, they're great. very convenient. if I notice an accesskey on a site I visit often, I make use of it. I would disagree with [HTML5 dropping accesskeys] more than longdesc. accesskeys, are really useful, and again I tend to use them whenever I come across them. it's a shortcut to get to where you want to go, instead of having to search for it. Regards, Simon Pieters
Re: [whatwg] On accessibility
Simon Pieters wrote: I've spoken to a person who is blind about HTML5 and accessibility. I thought I'd send some of his thoughts to the list. ... He also says that he accesskeys shouldn't be dropped. Accesskey implementations need to be seriously improved if they are to be retained. There's significant evidence to show that there are very few, if any, safe keys available which don't clash with existing shortcut keys in browsers. http://www.wats.ca/show.php?contentid=43 If implementations can be modified so that accesskeys do not interfere with existing shortcut keys, then that's great. Perhaps they could offer a kind of web-apps mode where all Alt+[key] combinations are safe to be used by the web page, and then another mode where they retain their normal browser functions. But until something like that happens and proves successful, accesskeys should not be retained. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] On accessibility
On Thu, 15 Jun 2006 08:09:43 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Accesskey implementations need to be seriously improved if they are to be retained. There's significant evidence to show that there are very few, if any, safe keys available which don't clash with existing shortcut keys in browsers. What Opera does makes sense. Maybe it should be standardized. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] On accessibility
On Jun 14, 2006, at 9:47 PM, Alexey Feldgendler wrote: On Thu, 15 Jun 2006 08:09:43 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Accesskey implementations need to be seriously improved if they are to be retained. There's significant evidence to show that there are very few, if any, safe keys available which don't clash with existing shortcut keys in browsers. What Opera does makes sense. Maybe it should be standardized. ... What Opera does is indeed very cool, but it's quite possible that another browser could come up with something even cooler. And in this area there is very little benefit from interoperability, so I don't see any point in standardizing it. It would be like standardizing on vi. (Or emacs.) (There is actually *harm* from interoperability for accesskey=, from Web authors cluttering pages with instructions on how to use access keys because they're so non-obvious -- instructions that may be incorrect for some platforms, depending on how they're worded, and that are irrelevant for non-interactive UAs like Google.) -- Matthew Paul Thomas http://mpt.net.nz/
