| french | english |
 |
|
| Créer un compte | |
| 21-03-09 / 01:09 : Accessibilité / DOM / Applications hybrides (cjed) |
| Ross Boucher propose une discussion au sujet de la spec WAI-ARIA, qui traite de l'accessibilité (et est centrée sur l'évolution de DOM). Comme souvent les commentaires à cet article apportent des informations très intéressantes (réponse d'un membre de la specification notamment). Voici mes réflexions sur ces points : La manipulation d'un document (HTML, XML) dans un navigateur ne peut être effectuée qu'en modifiant l'arbre DOM (les noeuds existants ou ajout de nouveaux noeuds), via un langage qui sera à priori le javascript (on peut le faire dans tout autre langage dans un autre contexte). La spec WAI-ARIA se base donc sur DOM pour proposer des comportements favorisant l'accessibilité. Les applications web sont à présent hybrides, constituées non seulement d'un document, mais également d'éléments hétérogènes inclus : élément Flash, élément canvas, WebKitView, etc. Ces éléments apportent des solutions à des problèmes particuliers (fonctionnalités ou performances non permises par un document, même si HTML5 étend la norme - tags vidéo, database storage) : animations, 3D, etc. (les parties purement textuelles restant logiquement en DOM, sauf cas de texte animé ou zoom, ou éditeur comme Bespin, basé sur Canvas). A noter que les CSS Animations de WebKit reposent également sur une séparation modèle (définition de l'animation en CSS) et langage de manipulation. Un document peut se passer de javascript mais du javascript ne peut s'exécuter hors du contexte d'un document. Ces différents éléments doivent communiquer entre eux pour répondre aux actions de l'utilisateur, ce qui pour le moment ne peut se faire que par DOM (action dans un élément Flash qui entraîne la modification du contenu du document par exemple). On parle alors d'accessibilité des APIs, qui peut concerner des éléments hétérogènes du container, ou un accès du container vers le système lui-même (afin de bénéficier de fonctionnalités non disponibles dans le navigateur, ou bien d'optimisations). Apple propose d'ailleurs via les WebKitView le moyen d'accéder à l'accélération 3D (pour les transforms) sur iPhone (accès à Cocoa - sur mac uniquement - depuis Javascript - via object WebScriptObject et JavascriptCore). L'accessibilité du point de l'utilisateur (zoom sur partie du texte, texte souligné, etc.) nécessite également la communication entre les différents éléments, et ramène donc à la question de l'accessibilité technique. En fait l'accessibilité technique (communication entre containers différents au sein d'un navigateur, ou entre un container du browser et le système) devrait être nommée availability pour éviter toute confusion. |
| Commentaires |
About containers inter-communication (that is on browser, not system/external function call) we can read a thread about controlling a Flash movie (passing parameters) from a Cappuccino application. For that to work, the CPFlashView has to provide access to some Flash embed's DOM node attributes (and requires a name attribute on the _DOMEmbedElement to get the right Flash handle). On the other way (Flash-->Cappuccino) the Flash ActionScript code has to have access to the Cappuccino root DOM element (that is normally hidden by the framework). |
| Poster un commentaire |