Re: Change proposal for ISSUE-85

Sam Ruby, Sun, 06 Jun 2010 11:58:12 -0400:
> On 06/06/2010 10:40 AM, Steven Faulkner wrote:
>> On 06/05/2010 09:34 PM, Ian Hickson wrote:
>>> Don't allow people to use ARIA to write inaccessible documents.
>> 
>> ARIA does not allow people to write inaccessible documents. Vague
>> statements  and lack of machine checkable conformance criteria in the
>> HTML5 specification in relation to the overloading and overriding of
>> elements default semantics and behaviours is the cause. ARIA merely
>> provides the author with the opportunity to communicate her authoring
>> intentions unambiguously via an accessibility API.
>> 
>>> ARIA is useful for authors who need to make new widgets that HTML 
>>> doesn't yet support. Buttons are supported by HTML, and therefore 
>>> there is no reason for an author to make a link act like a button
>>> to ATs.
>> 
>> ARIA is also useful when authors for whatever reason decide to modify
>> or extend the behaviour of a supported HTML element, which they often
>> do.`q
> 
> Examples?

Speaking of buttons vs anchor elements, then here is a forms expert 
that recommends, this, where each element looks like a button: [1]

	<button>Save</button> <a>Change Password</> <a>Cancel</a>

Note also that many, also in this group, has suggested that <input 
type="reset"> is useless and should become non-conforming. [2][3]

Speaking of another group of elements with "strong native semantics" 
[4] and which HTML5 therefore forbids changing the role for, then Tab 
presented an example in a discussion with Charles back in in November: 
[5]

  ]]
> I may be wrong, though - there may be cases that I just haven't run
> into where the most logical thing really *is* to use an <h1> but treat
> it as a button.
>
> (Actually, I may know of one - some accordion structures use headings
> as the toggler for their section.  In that case, is it most helpful to
> expose the heading as a button?  I truly don't know, and would
> appreciate some guidance on the matter.)

Given the lack of list-specific headings, and given the value to real  
users of being able to navigate an outline or structure via the 
headings,  
I would say you have just provided a very sound use case - thanks very  
much.
  [[

>>> Making a link act like a button to ATs while leaving it as a link for
>>> non-AT users will lead to non-AT users having a confusing experience,
>>> since the author will think the link is going to appear as a button to
>>> users and may refer to it as such.
>> 
>> If it is acts like a link then it should be presented as a link to all
>> users, if it acts like a button the it should be presented to all
>> users as a button. making a link look and act like a button for some
>> users, but not conveying this to other users will result in a
>> confusing experience.
> 
> Do you both agree with the following statement?
> 
> Making a link act like a button to non-ATs while leaving it as a link 
> for AT users will lead to AT users having a confusing experience, 
> since the author will think the link is going to appear as a button 
> to users and may refer to it as such.

How do "non-AT users" know whether a link has been "left as a link" or 
whether it is meant as a button button?  If a link has been made to 
look like a button via an image or CSS, then it ceases to look as 
button once you disable CSS or images. OTOH, someone with images or CSS 
disabled (or not supported by the UA) usually knows about this 
limitation, and so one will take this into account when communicating 
with e.g. screen reader users.

[1] http://particletree.com/features/rediscovering-the-button-element/
[2] http://www.w3.org/mid/6E9C6F8D-27FB-42D6-8D4D-2FE4D2A1F543@apple.com
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7699
[4] 
http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria
[5] http://lists.w3.org/Archives/Public/public-html/2009Nov/0341.html
-- 
leif halvard silli

Received on Sunday, 6 June 2010 18:53:26 UTC