Confirmed users
1,085
edits
Accessibility/JSON ARIA: Difference between revisions
→Defining the widget
XFallenAngel (talk | contribs) |
DavidBolter (talk | contribs) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 58: | Line 58: | ||
===XUL, SVG=== | ===XUL, SVG=== | ||
XUL | XUL and SVG don't define the <link> tag, an open question is how the roles can be included in such documents. | ||
* 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. | |||
** 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: | |||
<pre> | |||
<binding id="foobar"> | |||
<resources> | |||
<stylesheet src="chrome://calendar/skin/foosheet.css"/> | |||
<aria-roles src="chrome://calendar/content/access/roles.json/> | |||
<aria-roles src="chrome://calendar/locale/access/roles-l10n.json" l10n="true"/> | |||
</resources> | |||
... | |||
</binding> | |||
</pre> | |||
== Authoring content with the new widget == | == Authoring content with the new widget == | ||
| Line 75: | Line 88: | ||
If you care about validation, you need to write a DTD or schema that handles the new properties. | If you care about validation, you need to write a DTD or schema that handles the new properties. | ||
== | == Defining the widget == | ||
Example: buddy widget | Example: buddy widget | ||
| Line 110: | Line 123: | ||
[ "ignored", "boolean" ], | [ "ignored", "boolean" ], | ||
"passiveProperties": [ <!-- AT should not notify user of changes, but should still present these properties when the object receives | "passiveProperties": [ <!-- AT should not notify user of changes, but should still present these properties when the object receives focus --> | ||
<!-- prop attribute name, data type, optional l10n string --> | <!-- prop attribute name, data type, optional l10n string --> | ||
[ "idle", "string" ], <!-- readable string --> | [ "idle", "string" ], <!-- readable string --> | ||