346
edits
Accessibility/JSON ARIA: Difference between revisions
→XUL, SVG
XFallenAngel (talk | contribs) mNo edit summary |
|||
| Line 61: | Line 61: | ||
* One suggestion is to create a new processing instruction like: <code> <?xml-aria href="chrome://calendar/content/access/roles.json" type="text/json"?></code> | * One suggestion is to create a new processing instruction like: <code> <?xml-aria href="chrome://calendar/content/access/roles.json" type="text/json"?></code> | ||
* Also, since XUL has XBL, and this is effectively a new widget, we could require that it be a new element. The nsIAccessibleProvider interface used in XBL could be extended to provide a property that points to the JSON file. Or, in XBL we could actually directly define the properties that would have been in the JSON. | * Also, since XUL has XBL, and this is effectively a new widget, we could require that it be a new element. The nsIAccessibleProvider interface used in XBL could be extended to provide a property that points to the JSON file. Or, in XBL we could actually directly define the properties that would have been in the JSON. | ||
** Fallen: processing instruction has the advantage that its a more general form of inclusion, which could possibly lead to allowing aria extensions for any type of XML document. | ** Fallen: processing instruction has the advantage that its a more general form of inclusion, which could possibly lead to allowing aria extensions for any type of XML document. Aaron: I think we might want to allow either. If XBL is available though I suggest to put it there as part of widget definition. | ||
** Fallen: In XBL, we could probably use the <resources> block to add something, i.e: | ** Fallen: In XBL, we could probably use the <resources> block to add something, i.e: | ||
<pre> | <pre> | ||
| Line 75: | Line 74: | ||
</binding> | </binding> | ||
</pre> | </pre> | ||
== Authoring content with the new widget == | == Authoring content with the new widget == | ||