-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARIA roles #16
Comments
I'm in favor for this, but you think of this as a feature or the only way of knowing how to inject elements? |
It's a plus, not mandatory. Many webapps override native controls (like boxes) with custom-implemented widgets (like those found on YUI, jQuery-UI and extjs). ARIA roles allow these widgets to express their meaning, so we could populate them like boxes and not just ordinary s (which lack these semantics).
Many of these widget libraries already implement ARIA roles, and even though they create these roles client-side, it is possible to have these semantics server side (we would be the first project to do so). |
A plus addition to that feature is to implement/understand http://schema.org/... to me it is even better than ARIA roles... |
+1 on schema.org compatibility But I don't think this is an either/or comparing apples with apples. ARIA uses semantics to define functionality (widget) whereas schema.org semantics can be equated to microformats semantics if we had to compare and choose a specific "standard" but I think alganet's call to support ARIA is still valid besides supporting schema.org. Unless I am mistaken here? Some more on what is nothing more than a buzz word really: It's not really adding anything we don't already have, how do you propose this impacts the current state of the Template project? What needs to be added? |
I believe both ARIA and any kind of microdata could help (only if the microdata is an already standard, we shouldn't create our own like tal templates or anything). Raw HTML already have semantics. We should know that given this template:
And this PHP code:
The result must be an li element for every array item, if they're scalar. A form element could be populated by a filtered $_POST variable, a select element could be filled with an array of keys and values that maps to option names and contents and so on. If the template is a set of HTML elements that behave like a select element, we can expect to feed it the same way. A lot of rich widgets could be built this way. We could kind of hack an accessibility standard to help out template library to access elements easily. Microformats and Schema.org data could also be used to feed the templates. If some element has the vcard structure, we could fill it with a simple multi-dimensional array of keys and values corresponding to the hcard classes. |
Even though the: <ul>
<li></li>
</ul> Makes perfect sense, is even intuitive, in it's simplicity as would: <table>
<tr>
<td></td><td></td>
</tr>
</table> be for multidimensional data, yet there is no reason why we should treat this any differently to say <div class="person">
<h3 class="full-name"></h3>
<em class="email"></em>
<a class="homepage"></a>
</div> for example. This is the trend nowadays: ...to be continued.... |
http://www.w3.org/TR/wai-aria/roles
Ok, I believe this could be a major selling point for Respect\Template.
Anyone familiar with WAI-ARIA? ARIA roles are tied to HTML elements to specify how UI behaves. For example, one could apply tree roles to a simple set of DIVs and browsers and/or screen readers would know how to represent these DIVs as a navigable tree (fixing keyboard navigation, speech and so on).
We currently have plans to inject data structures to HTML elements by their semantics. For example, a multi-dimensional array could map to table rows and cells. By using ARIA roles in HTML, we could expand these semantics in a standardized way.
One could think of ARIA roles in Respect\Template as view helpers. W3C approved.
Please @augustohp tell me your thoughts on this.
The text was updated successfully, but these errors were encountered: