semantic markup for web application interfaces?
Home / Site Building & Testing / semantic markup for web application interfaces?
a touchy subject that can often turn into a philosophical debate, but i'd still be interested in some thoughts:
in a comment to bruce lawson's view on WCAG 2, jim/eatyourgreens asks:
| eatyourgreens wrote: |
| I had some thoughts on semantic HTML and Ajax (basically - HTML is a markup language for text documents. Does it have any semantic meaning when you start using it to mark up application user interfaces?) |
my first gut reply
| redux wrote: |
| as HTML is the only language that is mostly understood by user agents - including screen readers and the like -, HTML is all you gonna be able to use to mark up the output of your web application interfaces at this stage. of course, once we move down a more specialised route (e.g. an internal app using XUL), you’ve got a more sensible set of controls/elements, and i seem to recall that there’s at least a minimum of integration with MSAA on Windows…so you could start taking advantage of more semantically relevant markup there. |
at the risk of dredging up the whole "but it's a web application, so the web content accessibility guidelines don't apply" (which is a strawman anyway...if your app has an interface and output that is delivered via a web browser, i'd say that that is just as much content as anything else), what do you think?
_________________
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share: 
I agree with Redux. Any HTML output being processed by a web device is essentially what WCAG covers. The only difference is the way the HTML gets into the user agent; whether it is loaded from a static file on a server, generated via PHP from a database or is the result of an AJAX interaction.
However it gets there, it's still HTML being presented to the user via their user agent.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
I agree too - the content in a web application is still content, and should still be semantically described to the best extent possible.
Share:
| redux wrote: |
| as HTML is the only language that is mostly understood by user agents - including screen readers and the like -, HTML is all you gonna be able to use to mark up the output of your web application interfaces at this stage. of course, once we move down a more specialised route (e.g. an internal app using XUL), you’ve got a more sensible set of controls/elements, and i seem to recall that there’s at least a minimum of integration with MSAA on Windows…so you could start taking advantage of more semantically relevant markup there. |
Oh I agree completely. I was thinking that when you have something like google maps, where the document doesn't cleanly break down into headings, paragraphs, lists, blockquotes etc., then the issue is less one of 'have I used my HTML tags in the most semantically correct fashion" and more one of "have I got a clean, well-structured document? Is it as easy to navigate/use with a keyboard as it is with a mouse?" That sort of thing.
Because I could see that it would be very easy to mark up a web app interface using only divs, and this might make it a complete not a very nice person to use with a screenreader.
| redux wrote: |
| at the risk of dredging up the whole "but it's a web application, so the web content accessibility guidelines don't apply" (which is a strawman anyway...if your app has an interface and output that is delivered via a web browser, i'd say that that is just as much content as anything else), what do you think? |
Would it be worth looking at the user-agent guidelines too, particularly if you're doing things like drag-and-drop?
I'm thinking of games like the Tintin language game there:
http://www.nmm.ac.uk/...
At the moment, I'm leaning towards thinking that things like that might be more accessible if done with the latest version of Flash, rather than javascript. I think it's easier to do keyboard control in Flash, for a start. But that's a seperate issue from semantic HTML.
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
| redux wrote: |
| at the risk of dredging up the whole "but it's a web application, so the web content accessibility guidelines don't apply" (which is a strawman anyway...if your app has an interface and output that is delivered via a web browser, i'd say that that is just as much content as anything else), what do you think? |
I agree completely. It's a bit like judges and the law - sometimes we need to consider the intent behind the guideline rather than arguing over the meaning of individual words and phrases to justify our position.
_________________
Dan Champion, Champion IS, Mooch Marketing, Revish
Share:
"Web Application" is a designer term. As far as the end user is concerned there is no distinction between a single static page containing poetry and an interactive portal chocked full of complex forms and controls. To them both are just websites. In short, if both are being accessed is the same way then the same set of rules apply to both._________________
Paul
Share:
| Paul wrote: |
| "Web Application" is a designer term. As far as the end user is concerned there is no distinction between a single static page containing poetry |
That's a good point - if you want to mark up poetry, you have to use TEI. HTML doesn't have any tags for poetry and prose. Which is what I was getting at - HTML is a generic markup language that tries to cover all sorts of different document types and be all things to all people. There's a danger of getting hung up on the correct usage of the tags when what's more important is the usability of the pages.
So I think validity and good structure are important. Semantics I'm not so sure about.
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
| eatyourgreens wrote: |
| There's a danger of getting hung up on the correct usage of the tags |
HTML is indeed a very limited set of fairly generic tags (coupled with a few that, in my mind, are just too overly specific, such as ADDRESS and the different variants of CODE, VAR, etc).
| eatyourgreens wrote: |
| So I think validity and good structure are important. Semantics I'm not so sure about. |
however, in the context of HTML, good structure and semantics go hand in hand. a structure isn't really "good" unless it at least makes some kind of semantic sense. simply sticking with a whole bunch of generic DIVs and SPANs is only marginally better than simply sending plain text. if a reasonably close "semantic" element exists that can encapsulate at least a certain amount of meaning of your content, you should favour that over something purely generic.
but, as with everything, you've got to be pragmatic - unless you enjoy pedantic discussion of "the one and only true way(tm)" to mark something up correctly.
_________________
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
| redux wrote: |
|
HTML is indeed a very limited set of fairly generic tags (coupled with a few that, in my mind, are just too overly specific, such as ADDRESS and the different variants of CODE, VAR, etc). |
CITE? A nice idea on paper but bloody useless in practice.
| redux wrote: |
| however, in the context of HTML, good structure and semantics go hand in hand. a structure isn't really "good" unless it at least makes some kind of semantic sense. simply sticking with a whole bunch of generic DIVs and SPANs is only marginally better than simply sending plain text. if a reasonably close "semantic" element exists that can encapsulate at least a certain amount of meaning of your content, you should favour that over something purely generic. |
That's where my train of thought was going - divs and spans might be more semantically correct in certain cases, but they aren't useful to users of assistive technology. I like the idea of don't use a generic tag when a more specific one would do the job.
I think I've possibly been a wee bit pedantic about the use of the word 'semantic'
| redux wrote: |
| but, as with everything, you've got to be pragmatic - unless you enjoy pedantic discussion of "the one and only true way(tm)" to mark something up correctly. |
God, no. If anyone tries to start any of that at @media, I'll poke them with the nearest pointy object until they stop.
Now, if anyone wants to talk about how to best mark up historical documents (letters, logs, journals etc.) so as to digitally preserve their content for Future Generations(tm) - that I could probably go on about for hours. I read a very interesting paper last week on the need for presentational, not semantic, markup languages when digitising medieval texts. There you go. Forgot to bookmark the URL, though, like an idiot.
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
| eatyourgreens wrote: |
| Now, if anyone wants to talk about how to best mark up historical documents (letters, logs, journals etc.) so as to digitally preserve their content for Future Generations(tm) - that I could probably go on about for hours. I read a very interesting paper last week on the need for presentational, not semantic, markup languages when digitising medieval texts. There you go. Forgot to bookmark the URL, though, like an idiot. |
of course, those are situations where presentation IS meaning. i always think of the typographic montage of some futurist poetry.
in those circumstances it's obvious that the documents should be preserved with a vocabulary that's far richer and fit for purpose than HTML. in many cases, delivering those kinds of things on the web today will have to take the form of SVG or images.
_________________
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
Totally yeah - when I first tried to write SVG I couldn't get my head round it, for just that reason. I had learned to avoid presentational markup, but SVG is 100% presentational markup.
Share:
| redux wrote: |
|
of course, those are situations where presentation IS meaning. i always think of the typographic montage of some futurist poetry. |
Don your tweediest of tweed jackets and have a look at http://strange.mcmaster.ca/...
(warning - may cause spontaneous outbreaks of extreme pseudery).
| redux wrote: |
| in those circumstances it's obvious that the documents should be preserved with a vocabulary that's far richer and fit for purpose than HTML. in many cases, delivering those kinds of things on the web today will have to take the form of SVG or images. |
Welcome to the exciting world of XML for libraries and archives. Hadn't thought about SVG but there's lots and lots of stuff out there about encoding digital archives using languages derived from SGML.
I found this, which seems to summarise my thinking in the section entitled "HTML is pretty un-semantic":
http://semantichumanities.wordpress.com/...
That talks about academic texts marked up with TEI. For user interfaces, I suppose you could (if you were possessed by the spirit of extreme geekery) mark up your controls, button sets, panes etc. with XUL (or some equivalent, like the one Macromedia invented for Flex,which I can't remember the name of). When you want to deliver them to a web browser, transform them to (X)HTML using the transformation technology of your choice. Decide which structural HTML elements to use based on how the end user will actually use the resulting web page, keeping accessibility firmly in mind. Or am I talking complete nonsense now?
EDIT: I started to write up the thoughts I referred to initially on Bruce's blog. It turned out to be rather long, so here's a link:
http://eatyourgreens.org.uk/...
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
Turning the question on it's head:
| Quote: |
| why shouldn't web application authors strive for semantic meaning? |
To be honest, outside of laziness and speed I can't think of a reason. Certainly to make sure everything is correctly marked-up (to the limited levels you can stretch the semantic document metaphore into applications), does take a little longer, but the longer term usability benefits are clear.
I'm suprised no one has brought up ATAG since if you are working with any web based application that is sharing content/data with other web based users you have in effect to whatever level an authoring tool?
_________________
Red Ant
Share:
| Richard Conyard wrote: |
|
I'm suprised no one has brought up ATAG since if you are working with any web based application that is sharing content/data with other web based users you have in effect to whatever level an authoring tool? |
Either that or the user-agent guidelines - you might be building something like the Mozilla Amazon Browser or using the new Yahoo widgets in your own web pages. Not authoring content but browsing through data of some sort.
All I could find in the accessibility guidelines was the following rather vague help:
| WCAG1 wrote: |
| Guideline 8. Ensure direct accessibility of embedded user interfaces.
Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc. When an embedded object has its "own interface", the interface -- like the interface to the browser itself -- must be accessible. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided. Note. For information about accessible interfaces, please consult the User Agent Accessibility Guidelines ([WAI-USERAGENT]) and the Authoring Tool Accessibility Guidelines ([WAI-AUTOOL]). |
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
Page 1 of 1
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum