Support for @role=presentation?
Derek Featherstone
I've been looking (unsuccessfully) for some indication of which screen
readers support role="presentation"
I've looked in the codetalks wiki, and elsewhere, but I just don't see
any indication of current levels of support.
Can anyone provide any pointers to documentation? I'm really hoping
that i'm missing something, as my preliminary results with some
testing that I'm doing are rather disappointing :)
Cheers,
Derek.
--
Derek Featherstone fea...@furtherahead.com
tel: +1 613-599-9784 1-866-932-4878 (toll-free in North America)
Work: http://www.furtherahead.com
Blog: http://www.boxofchocolates.ca
Steven Faulkner
my understanding is its not so much the AT that support it, its the browsers,
so for example in IE8 when an img has role="presentation", its not
exposed via MSAA
or in firefox 3 when an image has a role="presentation" its not
exposed in the accessible DOM tree.
i just checked these cases and checked with JAWS in both browsers an
image is not announced even though it has an alt, when it has a
role="presentation"
regards
stevef
2009/4/6 Derek Featherstone <fea...@furtherahead.com>:
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
Derek Featherstone
Thanks for the clarification on which part of the stack has
responsibility for @role=presentation.
> i just checked these cases and checked with JAWS in both browsers an
> image is not announced even though it has an alt, when it has a
> role="presentation"
the impression that this simply wasn't for images, but for any node
that "should not be exposed" to AT via whatever means.
Are there simple published test cases for a variety of node types or
should we be creating them? I didn't see a comprehensive set of test
cases out there (on the wiki or otherwise)...
Thanks,
Steven Faulkner
> the impression that this simply wasn't for images, but for any node
> that "should not be exposed" to AT via whatever means.
> Are there simple published test cases for a variety of node types or
> should we be creating them? I didn't see a comprehensive set of test
> cases out there (on the wiki or otherwise)...
regards
steve
2009/4/6 Derek Featherstone <fea...@furtherahead.com>:
Aaron Leventhal
Firefox does not expose accessible nodes for elements role="presentation", so the screen reader simply doesn't see them. In addition, if you put role="presentation" on a table Firefox does not expose any table-related descendants (td/th/tr/tbody/thead) either. That's a useful way to indicate that a table or div are being used for layout. For an img, it's possibly better to use alt="" since that may work in more places, but I suppose it might be good to test that idea.
Loretta Guarino Reid
> It depends on the browser unless the AT is reading the DOM directly. Some
> ATs read the DOM directly for virtual buffer modes etc.
>
> Firefox does not expose accessible nodes for elements role="presentation",
> so the screen reader simply doesn't see them. In addition, if you put
> role="presentation" on a table Firefox does not expose any table-related
> descendants (td/th/tr/tbody/thead) either. That's a useful way to indicate
> that a table or div are being used for layout. For an img, it's possibly
> better to use alt="" since that may work in more places, but I suppose it
> might be good to test that idea.
>
> - Aaron
doesn't expose elements with role="presentation" to AT at all, how can
it expose the content of layout tables that have been marked with
role="presentation"? Does the interpretation of role="presentation"
depend on the type of element that has that attribute?
Loretta
Aaron Leventhal
The content of something with role="presentation" is exposed, just not an accessible object representing that element itself.
However, tables do something special. The td/th etc. descendant elements no longer make any sense since there is no table ancestor. Therefore, those elements are not exposed, but the other descendant contents of the table are still exposed.
This exposes nothing
<img role="presentation"/>
This exposes a single text node of "My text"
<div role="presentation">
My text
</div>
This exposes just 4 text nodes in a row:
<table role="presentation">
<tr>
<td>1</td>
<td>2</td>
</tr>
<tr>
<td>3</td>
<td>4</td>
</tr>
</table>
It may seem weird that table is an exception but again, those elements make no sense unless they're in a table. The author is saying that the table was being used for layout, so only the stuff the user cares about ( the content ) is exposed.
Loretta Guarino Reid
It makes me think that
<img role="presentation" alt="description provided" />
should expose the img with the alt text, since that is content. While
this combination of attributes doesn't make logical sense, is my
understanding correct?
Loretta
Aaron Leventhal
Actually that won't work, because the alt is not descendant content.
The whole element is wiped out from the accessible object tree. So you
could use that trick to read something to pre-ARIA browser users,
something like <img role="presentation" alt="Please upgrade to an ARIA-
enabled browser">
One other rule to keep in mind is that if something is focusable then
role="presentation" is ignored. It's too important that no matter
where a user navigates to a focus event is fired. After all, it's even
encoded in 508 that the focus is always exposed. Of course, it's an
oxymoron to do this. By definition if something is interactive it's
not for presentation, but I thought I'd point it out anyway.
- Aaron
Derek Featherstone
> This exposes a single text node of "My text"
> <div role="presentation">
> My text
> </div>
Why?
Are you saying that placing role="presentation" on that node means the
@role of presentation doesn't apply to descendant text nodes? Isn't
that breaking normal containership convention? Or am I
misinterpreting?
Rich Schwerdtfeger
Rich Schwerdtfeger
Derek Featherstone
<richs...@gmail.com> wrote:
> If the AT accesses the accessibility API, anything with role="presentation"
> disappears from the accessibility tree. So ATs which access only the
> accessibility API should be golden: NVDA, JAWS, Window-Eyes, Orca (Linux).
> ... JAWS I know does.
So that should include all of the contents of the node? therefore:
<div role="presentation">
Text goes here.
<em>Emphasized text here</em>
Final text here.
</div>
A screen reader encountering this should read nothing, given that the
entire div has a role of presentation, correct?
Thanks,
Aaron Leventhal
On Apr 7, 2009, at 2:51 AM, Derek Featherstone wrote:
>
> On Mon, Apr 6, 2009 at 3:38 PM, Aaron Leventhal <aa...@moonset.net>
> wrote:
>
>> This exposes a single text node of "My text"
>> <div role="presentation">
>> My text
>> </div>
>
> Why?
>
> Are you saying that placing role="presentation" on that node means the
> @role of presentation doesn't apply to descendant text nodes? Isn't
> that breaking normal containership convention? Or am I
> misinterpreting?
>
saying that the given element is there to help with the layout.
Some things in web world inherit to descendants and some don't.
There's no general rule for everything.
- Aaron
Aaron Leventhal
On Apr 7, 2009, at 4:51 AM, Rich Schwerdtfeger wrote:
> If the AT accesses the accessibility API, anything with
> role="presentation" disappears from the accessibility tree. So ATs
> which access only the accessibility API should be golden: NVDA,
> JAWS, Window-Eyes, Orca (Linux). ... JAWS I know does.
>
> Rich
Some of the ATs you list there may not just use the accessibility API
for everything. Specifically, some Windows screen readers may use
ISimpleDOMNode for their virtual buffer. I think we need someone to
test role="presentation" both in virtual buffers as well as in forms
mode, for each screen reader. Testing what happens for tables as well
as more basic scenarios is important.
- Aaron
Derek Featherstone
> That's just what role="presentation" does -- it doesn't inherit. It's
> saying that the given element is there to help with the layout.
>
> Some things in web world inherit to descendants and some don't.
> There's no general rule for everything.
Sure, I get that there's no general rule for everything.
I guess what I'm saying is that this seems counter-intuitive to me --
I was expecting the presentation role to apply to descendants.
Is there an ARIA alternative to role="presentation" that does *not*
expose the node's descendants to AT, via whatever mechanism for the
example I had posted earlier?
<div>
Text goes here.
<em>Emphasized text here</em>
Final text here.
</div>
Thanks,
Benjamin Hawkes-Lewis
> On Mon, Apr 6, 2009 at 10:51 PM, Rich Schwerdtfeger
> <richs...@gmail.com> wrote:
>> If the AT accesses the accessibility API, anything with role="presentation"
>> disappears from the accessibility tree. So ATs which access only the
>> accessibility API should be golden: NVDA, JAWS, Window-Eyes, Orca (Linux).
>> ... JAWS I know does.
>
> So that should include all of the contents of the node?
No.
> <div role="presentation">
> Text goes here.
> <em>Emphasized text here</em>
> Final text here.
> </div>
>
> A screen reader encountering this should read nothing, given that the
> entire div has a role of presentation, correct?
Incorrect. It _might_ read "Text goes here. /Emphasised text here/ Final
text here."
http://www.w3.org/TR/wai-aria/#presentation:
"The user agent MAY choose not to present all structural aspects of the
element being repurposed … while preserving the individual text elements
within them"
Note this is a "MAY" not a "SHOULD" or a "MUST". A user-agent could
comply to the draft by exposing a layout table as if it were data table,
AFAICT.
I'm not sure what the spec thinks it means by "text elements"; clearly
it includes text nodes, but attributes like alt and title could also be
called "text elements".
--
Benjamin Hawkes-Lewis
Aaron Leventhal
Don't think of it as hiding content from the user. Think of it as
saying that a given element is being used as tag soup to get the
formatting right across browsers
- Aaron
Rich Schwerdtfeger
Rich Schwerdtfeger
Derek Featherstone
> Don't think of it as hiding content from the user. Think of it as
> saying that a given element is being used as tag soup to get the
> formatting right across browsers
Right, I get that, for role=presentation. Is there an ARIA mechanism
that does what I'm suggesting? Some aria attribute that says "ignore
this node and its contents" -- that's what I'm after at this point.
Pretend that I never asked about role=presentation :)
If there is, I'd love to know. If there isn't, I'd love to know that as well.
Aaron Leventhal
Firefox we elected to look at whether the subtree really was hidden by
asking layout, and that overrides what aria-hidden says.
What's the use case? Maybe we made the wrong call in Firefox, and the
implementation guide should be changed to say that aria-hidden should
always rule if it exists.
As an evil workaround for now, you can use <img alt="HIdden content"
role="presentation"/>
- Aaron
Derek Featherstone
>
> There isn't right now. Potentially aria-hidden should do that, but in
> Firefox we elected to look at whether the subtree really was hidden by
> asking layout, and that overrides what aria-hidden says.
I was wondering about aria-hidden, but it looked more like that was
indeed an aria state that was designed to mirror the actual state,
much as you describe.
> What's the use case? Maybe we made the wrong call in Firefox, and the
> implementation guide should be changed to say that aria-hidden should
> always rule if it exists.
I think that's what I'd like, personally. In some cases I'd want the
contents of the subtree exposed for someone that *can* see the page,
but hidden where we've got aria attributes to do some of the work for
us.
> As an evil workaround for now, you can use <img alt="HIdden content"
> role="presentation"/>
Did you really just type that? ;)
Aaron Leventhal
> I think that's what I'd like, personally. In some cases I'd want the
> contents of the subtree exposed for someone that *can* see the page,
> but hidden where we've got aria attributes to do some of the work for
> us.
>
I think PFWG and the ARIA implementors will need a specific example of
where this is useful.
One case I was thinking of was, if there was a way to expose a "jump
to main content" link which would be exposed only if the current
browser/AT combo didn't support role="main". However, since focusable
items really need to always be exposed even in the aria-hidden case,
that might not be easy. We could try to expose the skip link only to
virtual buffers, like this:
<a onclick="browser.location="blah.com/#main" role="presentation"></a>
In theory that might only be noticed by the NVDA/JAWS/Window-Eyes
virtual buffer if ARIA was not supported. If ARIA was supported, on
the other hand, the role="main" later in the document would work.
But, that's just talk since I haven't tried it.
Anyway, can you give more info on your particular use case ideas?
- Aaron
Benjamin Hawkes-Lewis
> Anyway, can you give more info on your particular use case ideas?
Consider the tree widget example at the beginning of the ARIA draft.
For sighted users, this depends completely on background images to
indicate the open/closed status of branches. This will break for users
applying their own styles or with images disabled. This is a Bad Thing.
Something like:
<span role="completely-ignore-contents">(Open)</span>
<span role="completely-ignore-contents">(Closed)</span>
styled with the CSS3 reworking of the "content" property would create
indications that will work for such users too.
(In practice, today you'd probably use <img alt="Open"> or more brittle
forms of CSS image replacement using background-image because only Opera
and WebKit have reworked "content" to do image replacement, but you get
the idea.)
However, you wouldn't want that node exposed to users whose clients are
reporting the open/closed status via ARIA in some fashion, because then
the same information would be presented twice.
--
Benjamin Hawkes-Lewis
Aaron Leventhal
<img alt="Open" role="presentation" src="open.png">
But, the good news is that it will work in FF3. Need to check virtual
buffer modes of various screen readers though.
So if you want to hide stuff from ARIA users, use role="presentation"
with an img and alt text.
- Aaron
Benjamin Hawkes-Lewis
> You will have to do
>
> <img alt="Open" role="presentation" src="open.png">
> But, the good news is that it will work in FF3. Need to check virtual
> buffer modes of various screen readers though.
>
> So if you want to hide stuff from ARIA users, use role="presentation"
> with an img and alt text.
So in your view, when the spec says "text elements" it (should) mean
"text node children" (as opposed to attribute nodes, element children) etc.
While I think it would be appropriate for examples in the draft to use
this "img" markup (as "content" hasn't been finalized), what does happen
when you want the image kept in the CSS layer (where it logically
belongs) for skinning purposes? We don't want to be stuck using "img"
for that forever - and it's not likely to see wide adoption by libraries
trying to facilitate skinning.
--
Benjamin Hawkes-Lewis
Aaron Leventhal
node children.
Using img/alt/presentation is just a workaround until browsers and ATs
catch up to ARIA. So this is not forever. This is only useful in order
to gracefully degrade a11y right now.
- Aaron
Benjamin Hawkes-Lewis
> Using img/alt/presentation is just a workaround until browsers and ATs
> catch up to ARIA.
But how would catching up with ARIA solve the problem I mentioned for
users (partially or completely) applying their own styles - e.g. their
own color scheme? They aren't using special AT; they're just configuring
their browser.
--
Benjamin Hawkes-Lewis
Aaron Leventhal
image?), since this is a short term solution we're talking about, and
something like :before won't work in IE. Right?
So if use CSS for your expander image in the parent tree item, but you
still want to provide "collapsed" or "expanded" only to non-ARIA
screen reader users, you will probably need a hack to work around it.
You could add an additional invisible 1x1 transparent .png with this
info in the alt text. Again, we're talking short-term workarounds
here, until ARIA becomes more prevalent. Not pretty, but it could be a
workable solution if you really need one.
Another possibility for a tree view is just to fall back on nested
lists of links and don't provide a tree view. Just have a hidden image
on the top of the page advising users to upgrade to an ARIA solution.
There are after all, free browser-AT combos they can download which
support ARIA. And generally, widgets that mimic their desktop
counterparts like tree views will work with any screen reader as long
as the user has Firefox 3 or later. That's because Firefox just
exposes those widgets via MSAA or ATK, which the AT already uses in
forms mode.
I suppose the main downside of doing that would be Mac support. There
is nothing on the Mac which really supports ARIA yet.
- Aaron
Schnabel, Stefan
asked.
- Stefan
Benjamin Hawkes-Lewis
> I guess you will probably have to use background images or (list-item-
> image?), since this is a short term solution we're talking about, and
> something like :before won't work in IE. Right?
>
> So if use CSS for your expander image in the parent tree item, but you
> still want to provide "collapsed" or "expanded" only to non-ARIA
> screen reader users, you will probably need a hack to work around it.
> You could add an additional invisible 1x1 transparent .png with this
> info in the alt text. Again, we're talking short-term workarounds
> here, until ARIA becomes more prevalent. Not pretty, but it could be a
> workable solution if you really need one.
I think we're talking at cross-purposes. ;)
As far as I can tell, the conflict I'm talking about would exist even if
all AT and browsers supported ARIA and CSS3, as they are currently
drafted. Prevalence of support for these technologies would not improve
the situation without additional features.
There are four groups of users I'm talking about.
1. Users of AT that will read/braille the state via ARIA roles.
2. Users not using AT and consuming all publisher styles.
3. Users not using any AT and consuming a subset of publisher styles
(e.g. everything except they are enforcing their own color scheme and
rejecting CSS images, perhaps for colorblindness reasons).
"aria-expanded" cannot help these users. (If it can, then how can it?)
4. Users not using any AT and rejecting all publisher styles (for
whatever reason). I suppose "aria-expanded" could help these users if
anyone could work out appropriate default styling for the property.
As far as I can tell, the "right" way (assuming CSS3 support) to
indicate the tree item state to all four groups is to use a "span" whose
content is replaced with an image using 'content'. But if you do that,
there's no way to save Group 1 having to consume the information twice:
<li role="treeitem" aria-expanded="true"><span>Expanded:</span> Small
Breeds
If there was a way to indicate that the textual information in the
"span" was simply expressing information implicit in the ARIA properties
or, more crudely, a way to tell ARIA-inflected renderings to ignore the
supplementary text, then there would be a way to prevent duplicated
rendering.
Does that make sense?
--
Benjamin Hawkes-Lewis
Aaron Leventhal
> <span>Expanded:</span>
Why is that the "right" way, as opposed to
<span class="expanded"/>
Who is the text in there for at this point, if aria-expanded="true"
and the user has ARIA support?
- Aaron
Aaron Leventhal
On Apr 9, 2009, at 9:19 AM, Schnabel, Stefan wrote:
>
>> There is nothing on the Mac which really supports ARIA yet.
>
> True. But interesting is that the Mac lovers see that different, if
> asked.
any real ARIA support yet.
Don't take away my Mac, but let's be realistic :)
- Aaron
Benjamin Hawkes-Lewis
> On Apr 9, 2009, at 9:53 AM, Benjamin Hawkes-Lewis wrote:
>
>> <span>Expanded:</span>
>
> Why is that the "right" way, as opposed to
> <span class="expanded"/>
How would that communicate the information to a user who isn't using AT
and doesn't see images?
> Who is the text in there for at this point, if aria-expanded="true"
> and the user has ARIA support?
Groups 3 and 4 in my breakdown.
What would ARIA conformance do for those user groups?
--
Benjamin Hawkes-Lewis
Aaron Leventhal
<span role="img" aria-label="">expanded</span>
The img role will truncate the accessilbe object subtree.
I guess it will take some experimentation.
I'll admit I don't know everything about groups 3 & 4. It would be
good if I had more user data on who these people are and what the
benefits are to adding the word 'expanded". To be honest I'm
wondering how necessary that really is. Would some non-AT users
really want to see the word "expanded" right in the tree? Does this
give them something that the level of indentation doesn't? Honestly I
think that would just make the tree more confusing.
- Aaron
Rich Scwerdtfeger
safari 4 beta
Rich Schwerdtfeger
Sent from my IPhone handheld
On Apr 9, 2009, at 2:19 AM, "Schnabel, Stefan"
Schnabel, Stefan
Voice Over in Leopard final.
Is this the plan?
Rich Schwerdtfeger
Rich Schwerdtfeger
Benjamin Hawkes-Lewis
> Hmm, you could possibly do:
> <span role="img" aria-label="">expanded</span>
> The img role will truncate the accessilbe object subtree.
Interesting. By the current drafts, wouldn't the image's description
still be "expanded" and its text equivalent still be "expanded" even if
it's accessible name was ""?
> I guess it will take some experimentation.
>
> I'll admit I don't know everything about groups 3& 4. It would be
> good if I had more user data on who these people are and what the
> benefits are to adding the word 'expanded". To be honest I'm
> wondering how necessary that really is. Would some non-AT users
> really want to see the word "expanded" right in the tree? Does this
> give them something that the level of indentation doesn't? Honestly I
> think that would just make the tree more confusing.
You're right, sorry, my example's perhaps a bit off. Although tree UIs
do tend to distinguish between expanded items and leaf nodes as a hint
that users can close the former, it's "closed" that wouldn't be obvious:
* z
* b
* f
* g
* n
* q
* x
* c
It's obvious that some of those items are expanded. But there's no way
to distinguish closed items from items without children (other than
manually trying to open "z, "f", "n", "q", "x", and "c"). That's why
tree UIs must distinguish between an expandable node and a leaf node
(using a plus icon in Windows or a right-pointing arrow on OS X, for
example).
---
Benjamin Hawkes-Lewis
Benjamin Hawkes-Lewis
> You're right, sorry, my example's perhaps a bit off. Although tree UIs
> do tend to distinguish between expanded items and leaf nodes as a hint
> that users can close the former, it's "closed" that wouldn't be obvious:
>
> * z
> * b
> * f
> * g
> * n
> * q
> * x
> * c
>
> It's obvious that some of those items are expanded. But there's no way
> to distinguish closed items from items without children (other than
> manually trying to open "z, "f", "n", "q", "x", and "c"). That's why
> tree UIs must distinguish between an expandable node and a leaf node
> (using a plus icon in Windows or a right-pointing arrow on OS X, for
> example).
The problem is perhaps even clearer with another example from the spec:
<li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>
* Sort by Last Modified
Is that checked or unchecked?
--
Benjamin Hawkes-Lewis
kliehm
<ul role="tablist"><li role="presentation"><a role="tab">foo</a></li></
ul>
Screenreaders couldn't get that the tab belongs to the tablist because
they were not immediate children of tablist. Adding
role="presentation" to the list item fixed that, and screenreaders
announced "tab 1 of 4".
Octavian Râsnita
I've used Jaws 10 and Firefox 3 (I think the latest version) but the items
are shown as a simple list.
Thanks.
Octavian
----- Original Message -----
From: "kliehm" <goo...@martin-kliehm.de>
To: "Free ARIA Community" <free...@googlegroups.com>
Sent: Friday, April 17, 2009 3:28 PM
Subject: [free-aria] Re: Support for @role=presentation?
>