Skip to content
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

Open
alganet opened this issue Feb 27, 2012 · 6 comments
Open

ARIA roles #16

alganet opened this issue Feb 27, 2012 · 6 comments

Comments

@alganet
Copy link
Member

alganet commented Feb 27, 2012

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.

@augustohp
Copy link
Member

I'm in favor for this, but you think of this as a feature or the only way of knowing how to inject elements?

@alganet
Copy link
Member Author

alganet commented Feb 28, 2012

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).

@augustohp
Copy link
Member

A plus addition to that feature is to implement/understand http://schema.org/... to me it is even better than ARIA roles...

@nickl-
Copy link
Member

nickl- commented Jun 2, 2012

+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:
web semantics
POSH
semantic HTML

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?

@alganet
Copy link
Member Author

alganet commented Jun 17, 2012

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:

`<ul><li></li></ul>`

And this PHP code:

`$template['ul'] = array('Foo', 'Bar', 'Baz');

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.

@nickl-
Copy link
Member

nickl- commented Jun 18, 2012

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:
Pure - Iterative

QueryPath - Template

...to be continued....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants