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
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:
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
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
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
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
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
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
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
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
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
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
: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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,
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
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
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
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
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
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
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
39 matches
Mail list logo
