W3C home > Mailing lists > Public > public-pfwg-comments@w3.org > January to March 2008

Re: Processing requirements for secondary and seealso missing

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 26 Mar 2008 14:46:03 +0200
Cc: public-pfwg-comments@w3.org
Message-Id: <DB68951B-EDA6-47D5-8246-DC048E0682A6@iki.fi>
To: Lisa Seeman <lisa@ubaccess.com>

On Mar 26, 2008, at 12:39, Lisa Seeman wrote:
> Landmark roles such as secondary are from the XHTML roles

They are in the ARIA spec, though. While the XHTML Role Attribute  
Module spec is not relevant to HTML 5, people have expressed  
expectations of integrating ARIA with HTML 5.

I'm interested in how ARIA could be integrated with HTML 5. I talked  
with Hixie about this, and as it stands ARIA isn't ready for wholesale  
inclusion in HTML 5.

> I think the processing requirements in this case are simple - enable
> adoption to your user base needs.

That's totally vague. That's not a processing requirement that leads  
to interoperable implementations.

> It is not our thoughts  to dictate how your users need content, just  
> to
> enable you to adapt content for them.

Telling implementors to figure something out is not good enough.

> for example , many browsers may ignore secondary
>
> If this is a screen reader, maybe secondary content should be read  
> after
> main content

"May" and "maybe" don't sound convincing. As an author, how do I  
figure out whether using role=secondary makes sense? Writing semantics  
into a Web page / Web applications has a cost. Even when the cost  
isn't monetary, there's an opportunity cost.

Telling people to make an effort with a cost without any concrete  
indication about what the effort is supposed to accomplish is unkind  
to the people who are expected to make an effort and if you want them  
to trust expert advice on accessibility. If they figure out that you  
are asking them to spend time over practically nothing, they may  
ignore you even when what you are requesting would improve  
accessibility.

> This should also explain email "Spec is devoid of processing  
> requirements
> for states and properties"

It explains why the spec is the way it is, but it does not solve the  
problem.

If the ARIA spec fails to spell out implementable, realistic and  
detailed processing requirements, it isn't really the document  
specifying ARIA as far as implementors are concerned. Instead, the  
developer.mozilla.org wiki and the Gecko source code at  
mxr.mozilla.org become de facto normative (until another  
implementation leapfrogs Firefox on a particular ARIA feature at which  
point implementors will have to reverse engineer that implementation  
for that feature).

That's like going back to the bad old days of HTML 4. You can't  
implement an HTML browser that works with Web content by reading UA  
requirements from the HTML 4.01 spec. Instead, you needed to reverse  
engineer other browsers until HTML5 came along. Failing to put  
detailed processing requirements in the WAI-ARIA spec is like inviting  
someone else to write an ARIA5 eventually.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 26 March 2008 12:46:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:57 UTC