[SPMan]

Bei einem W3C WAI Test bekomme ich folgende Fehlermeldung:

Device dependant or device independent events that provide no device interoperability
<div id="steel" onclick="hideIt();"></div> is not device interoperable. Use proper event combinations to make it device interoperable.

Ich nehme mal stark an, dass das Problem das JavaScript ist. Da die Funktion nichts mit der eigentlichen Zugänglichkeit der Seite zu tun hat, sondern vielmehr nur ein "Feature" ist, frage ich mch, ob es eine Möglichkeit gibt dennoch den Test zu bestehen.

[SPMan]

Hallo,
ich habe nach einiger Recherche selbst die Lösung zu o.g. Problem gefunden:

Some event handlers, when invoked, produce purely decorative effects such as highlighting an image or changing the color of an element's text. Other event handlers produce much more substantial effects, such as carrying out a calculation, providing important information to the user, or submitting a form. For event handlers that do more than just change the presentation of an element, content developers should do the following:

Use application-level event triggers rather than user interaction-level triggers. In HTML 4.01, application-level event attributes are "onfocus", "onblur" (the opposite of "onfocus"), and "onselect". Note that these attributes are designed to be device-independent, but are implemented as keyboard specific events in current browsers.
Otherwise, if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):
Use "onmousedown" with "onkeydown".
Use "onmouseup" with "onkeyup"
Use "onclick" with "onkeypress"

Quelle

Dementsprechend habe ich den Quelltext angepasst:

<div id="steel" onclick='hideIt();' onkeypress='hideIt();'>

Auf meiner Suche ist mir zudem ein interessantes PDF vom Forschungsinstitut Technologie-Behindertenhilfe (FTB) "in die Hände gefallen":

Barrierefreies E-Government - Leitfaden für Entscheidungsträger, Grafiker und Programmierer

[Finnerty]

Hallo,

das onkeypress ist keine gute Idee. Auch wenn es in vielen Publikationen noch empfohlen wird. Mit Firefox ist die Seite damit praktisch nicht mehr mit der Tastatur zu bedienen. onclick reicht vollkommen. Das wird von allen Browsern und Hilfsmitteln korrekt interpretiert.

Siehe dazu auch:

Web Access Centre Blog :: Too much accessibility – multiple JavaScript event handlers

Too much accessibility – multiple JavaScript event handlers

A classic example of trying too hard and making accessibility bloopers, can be found when web authors provide too many JavaScript event handlers in an effort to ensure device independence. This is the fifth in our series of articles on “too much accessibility“.

Ensuring that users can make JavaScript events work, regardless of the way that they access your web page is vital. Users should be able to activate JavaScript events whether they use a mouse, keyboard, pointing / switch device or any other means of navigation.

However, if two or more event handlers, designed to perform the same task are used, the effect can be the opposite of the one you intended.

The most common problem is where onClick is used, and authors, believing that this is a mouse dependent event handler, will add an onKeypress, or similar to make sure that keyboard and switch users aren’t left out.

The problem here is caused by the belief that onClick is always mouse dependent. If the event is attached to a link or form control, onClick is device independent.

In Internet Explorer there is no effect when onClick and onKeypress are used together; the second handler is ignored. No surprise there then.

However in Mozzilla Firefox and Opera, the web author is taken at his word, and using onClick with onKeypress will activate the link or button, when all the user is trying to do is navigate over and passed it..

This kindly meant, but flawed technique has been seen in the wild, on a search button, which was preceded only by a link to the home page and the search input field.

This meant that if navigating by using the [tab] key, there were only two pages available, Home and Search Results. The intrepid user could, of course, hold down the [shift] key while tabbing, which reverses the tab order, but would you walk backwards into a shop?

oder

BITV-Bedingung 9.3 - Geräteunabhängige Eventhandler : Einfach für Alle

[SPMan]

Zitat von Finnerty

Hallo,

das onkeypress ist keine gute Idee. Auch wenn es in vielen Publikationen noch empfohlen wird. Mit Firefox ist die Seite damit praktisch nicht mehr mit der Tastatur zu bedienen. onclick reicht vollkommen. Das wird von allen Browsern und Hilfsmitteln korrekt interpretiert.

Wenn ich onclick alleine verwende bekomme ich aber eine Fehlermeldung bei den WAI-Test-Tools.

[Finnerty]

Naja, die Frage ist, was Dir wichtiger ist. Das bestehen einer automatisierten Überprüfung oder die praktische Nutzbarkeit deiner Website.

Versuch doch mal in Firefox ohne Maus mit der Tabulator Taste durch die Seite zu navigieren. Bei dem Link mit onkeypress wird es nicht mehr weitergehen. Das ist eine echte Barriere!

Ich würde auf die ganze automatische Testerei verzichten. Das Thema ist viel zu komplex um maschinell überprüft werden zu können. Oder sagt Dir dein Tool auch ob deine Alternativtexte für Grafiken sinnvoll und aussagekräftig sind?

Eine Alternative wäre vielleicht die BITV-Test Selbstbewertung. Das ist aber sehr aufwendig und lässt sich nicht mit einem Mausklick erledigen.
BITV-Test | Selbstbewertung | Startseite

[SPMan]

Zitat von Finnerty

Naja, die Frage ist, was Dir wichtiger ist. Das bestehen einer automatisierten Überprüfung oder die praktische Nutzbarkeit deiner Website.

Versuch doch mal in Firefox ohne Maus mit der Tabulator Taste durch die Seite zu navigieren. Bei dem Link mit onkeypress wird es nicht mehr weitergehen. Das ist eine echte Barriere!

Demnach wäre das Erreichen von "AAA+", wenn man keine echte Barriere errichten möchte mit "onclick", zumindest derzeit, nicht möglich?

Natürlich ist die echte Nutzbarkeit wichtiger, aber erkläre mal einen evtl. Kunden, der auf die Ergebnisse besteht, dass die Bedingungen veraltet sind.

Vor allem wird wohl davon ausgegangen, dass "onklick" mit einer evtl. Barriere gleichzusetzen ist, was z.B. gerade bei meinem Beispiel nicht so ist.
Ich habe extra alles daran gesetzt ein Drop-Down-Menü ohne JS für den IE einzusetzen.

Einen evtl. anderen "Trick" für die Umgehung dieses Problems gibt es wohl nicht, oder?

[Finnerty]

Zitat von SPMan

Einen evtl. anderen "Trick" für die Umgehung dieses Problems gibt es wohl nicht, oder?

aus BITV-Bedingung 9.3 - Geräteunabhängige Eventhandler : Einfach für Alle

... Es kann also passieren, dass eine Befolgung der Richtlinien bis ins letzte Detail Besucher aussperrt oder es Ihnen unnötig schwierig macht, eine Seite oder Anwendung zu benutzen. Falls Sie befürchten müssen, dass Ihre Seiten einem automatisierten Accessibilitytest unterzogen werden, dann können Sie für die Dauer des Tests ein zusätzliches onkeypress einbauen und hinterher wieder auskommentieren.

[SPMan]

Zitat von Finnerty

... ergo, zumindest "offiziell" nicht.
Hach... man hats nicht leicht, wenn man sich an "Standarts" halten möchte.

Vielleicht eine if-anweisung herzaubern: "Wenn Du einem automtisierten Test unterzogen wirst erscheine 'onkeypress'."

[Thorben]

Zitat von SPMan

Hach... man hats nicht leicht, wenn man sich an "Standarts" halten möchte.

Besonders wenn man sie richtig schreibt .

[SPMan]

Zitat von Thorben

Besonders wenn man sie richtig schreibt .

Asche auf mein Haupt!

PS: Falls jemand wider Erwarten doch noch eine Möglichkeit sieht bitte posten!