W3C home > Mailing lists > Public > public-html@w3.org > May 2011

[Bug 12710] New: @accesskey: Authoring conformance - reliance on @tabindex et cetera

From: <bugzilla@jessica.w3.org>
Date: Fri, 20 May 2011 02:45:10 +0000
To: public-html@w3.org
Message-ID: <bug-12710-2495@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12710

           Summary: @accesskey: Authoring conformance - reliance on
                    @tabindex et cetera
           Product: HTML WG
           Version: unspecified
          Platform: PC
               URL: http://dev.w3.org/html5/spec/editing#the-accesskey-att
                    ribute
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: xn--mlform-iua@xn--mlform-iua.no
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org
        Depends on: 12709


PROPOSAL:

Let the specification state that conformance checkers should stamp it an error
- or at least issue a warning - whenever @accesskey is added to an element
where it obviously has no effect.

For instance, if @accesskey is added to a non-interactive element  were there
isn't any @tabindex or anything else that makes the element focusable, then
@accesskey is pointless and even potentially harmful/confusing to users.

JUSTIFICATION - AUTHORS:

* It will save authors from pointless coding, including - dare I say - "cargo
cult" accessibility coding, if such elements are stamped as invalid or at least
triggers a warning.
* It will guide authors to use @accesskey in a way that creates the effect that
they want, if "dead" @accesskey usage is stamped as an error.

JUSTIFICATION - USERS:

If an element has the @accesskey, without having any effect that at least some
users can observe, then it is only confusing to users when they activate such
accesskeys and nothing happens. Such experiences may also make users not trust
its positive effects and thus ignored it when it works.

JUSTIFICATION- USER AGENTS:

The spec fails to require  that user agents do not list "dead" (non-working)
accesskeys to unfocusable elements to users. Therefore, it is necessary to
issue a warning/error message in validators, in order to minimize the problem
that auhors provide accesskeys which are without any effect and which, thus,
only would confuse users if they are presented for them.

EVIDENCE THAT AUTHORS MAKE THIS KIND OF MISTAKE:

  In W3C's online mailinglist archives, accesskey="j" is attached to an
unfocusable anchor element (without @href attribute): [*]

 <a name="start295" accesskey="j" id="start295"></a>
 [*] http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0295

EVIDENCE THAT USER AGENTS DO NOT HIDE 'dead' ACCESSKEYS:

* iCab can reveal access keys - and doesn't hide 'dead' accesskeys.
* Opera, when user wants to see the access keys, also lists 'dead' accesskeys

NOTES: 

This conformance checker related bug is a little bit related to the authoring
related bug 12708.
It also relates to bug 12709, which suggests that user agents should be
required to not reveal "dead" accesskeys.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 20 May 2011 02:45:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:24 UTC