Discussion on building custom components

There's an interesting discussion on building custom components on the 
webapps mailing list.

Anne van Kesteren refers to Ian Hickson's old post, about staying away 
from "proprietary markup":
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1142.html

In my experience, once you begin scripting, you have a "proprietary" 
situation, anyway.

Dimitri Glazkov responds that, if encapsulated with sufficient 
semantics, custom components can be made more accessible:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1187.html

In my experience, ARIA serves this purpose quite well.

Alex Russell puts forward an interesting thought: "non-trivial apps have 
*already* given up on HTML"
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1188.html

In my experience, a non-trivial application -should- maintain a full and 
rich HTML DOM. However, that HTML document is likely going to contain 
the manual, and other text-rich content, which is then re-used by the 
application. The application itself would be non-functional without the 
scripting environment, without the bootup sequence: essentially, the 
application is proprietary, unlike HTML documents. It only functions 
within its own construct.

I've found that, including all terminology from the application, with 
usable descriptions, in the DOM, means that ATs such as Google Translate 
can operate with the app. By maintaining elements within the Canvas 
subtree, and using ARIA, client-side ATs can interoperate with the 
application as they would any other native application on the OS. These 
are both hooks into HTML, and hooks into standard markup (ARIA). They're 
beneficial, regardless of ATs, as they ensure better boundaries between 
presentation and markup. Use ARIA and HTML semantics to guide your 
development, use WCAG to guide your project scope and quality.


-Charles

Received on Friday, 2 September 2011 21:09:26 UTC