Re: [user-context] What are the use cases for exposing screen reader or magnifier version info?

On Feb 5, 2013, at 12:00 AM, Dominic Mazzoni <dmazzoni@google.com> wrote:

> On Mon, Feb 4, 2013 at 4:38 PM, James Craig <jcraig@apple.com> wrote:
>> It would become more unwieldy when using larger data sets
>> Every time the table scrolled, you'd have to update your CSS rule offset.
>>>  aria-posinset: calc(index + 163);
> Isn't that less code the updating the attribute in each of the rows in the table? 

Perhaps I'm misunderstanding how you're proposing to modify this rule. 

The DOM modification is usually one line inside a loop you'd already be using to change the row contents from the table data provider anyway.

	// for each 
		item.updateContents(); // already doing this anyway
		item.setAttribute('aria-posinset', newIndex); // so this single-line addition is straightforward

If I'm understanding you correctly, you're proposing one of two things:

	1. Modify a CSSStyleDeclaration inside a CSSRule object from a CSSRuleList, from a CSSStyleSheet.
	2. CSSStyleSheet.deleteRule() followed by CSSStyleSheet.insertRule() 

In either case, I expect the a more code, more complexity, and probably more rendering overhead when re-parsing and displaying the updated style sheet.

But then, perhaps I'm misunderstanding what you're proposing.

>> Why bury functional information specific to one control inside a CSS rule? IMO, it's much better to store this on a DOM attr, even if it is more verbose.
> 
> You could make the same argument against CSS.

For Class variable modifications like defining a role for a selector match (e.g. ~"ul.tabs li { role: 'tab'; }" ), I'm right there with you (that's what PFWG-ISSUE-119 is about) as long as the element's applied role/attrs/etc are programmatically determinable from the HTMLElement object, but for Instance variable modifications like posinset, I think a CSS-like approach is a bad match. 

If you can define it cleanly, like your straw man (aria-posinset: calc(index + 1);), then it's not even necessary because the UA can determine the set size and position already. If you can't determine the set size and position because the DOM is incomplete (like the example below), then you don't get any benefit from defining it in a CSS-like fashion.

<!-- no need for setsize and posinset here b/c all elements are in the DOM tree -->
<ul role="listbox" aria-labelledby="label_fruit">
	<li role="option"> apples </li>
	<li role="option"> bananas </li>
	<li role="option"> cantaloupes </li>
	<li role="option"> dates </li>
</ul>

<!-- need setsize and posinset here b/c DOM tree is incomplete; defining in CSS would result in many arbitrary or frequently updated rules. -->
<ul role="listbox" aria-labelledby="label_fruit">
	<!-- items 1-4 are not in the DOM -->
	<li role="option" aria-setsize="16" aria-posinset="5"> apples </li>
	<li role="option" aria-setsize="16" aria-posinset="6"> bananas </li>
	<li role="option" aria-setsize="16" aria-posinset="7"> cantaloupes </li>
	<li role="option" aria-setsize="16" aria-posinset="8"> dates </li>
	<!-- items 9-16 are also not in the DOM -->
</ul>

> I think there are several potential arguments in favor:
> 
> From a design perspective, I agree it's a matter of taste - but I can see circumstances where web developers might love keeping ARIA details out of the HTML so that content creators can feel free to hand-edit HTML.

I think those circumstances lend themselves well to something like XBL, BECSS, or HTC, which may be considered for ARIA 2.0.

ISSUE-119 (XBL for ARIA2): Consider use of a technology like XBL or BECSS to assign ARIA semantics (roles/state/props) and event handlers [ARIA 2.0]
http://www.w3.org/WAI/PF/Group/track/issues/119

> From a performance perspective, many web developers have experienced ARIA slowing down page load time. Top web properties are obsessive about speed and size (see [1], [2]), and I think it's really important that accessibility isn't seen as something that burdens and slows down sites.

I'm not convinced that gutting a style sheet rule object on the fly would be any faster for the renderer.

> Finally, this could make it easier to take existing code and make it accessible. Refactoring existing code to make it possible to add ARIA at the right times is not always easy, and adding style rules might be simpler and less risky.
> 
> - Dominic
> 
> [1] http://blog.tagman.com/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/
> [2] http://blog.kissmetrics.com/loading-time/

Received on Wednesday, 6 February 2013 00:00:16 UTC