Hello all, What are your thoughts around landmark roles? Couple of comments and questions: 1. As of now, landmark roles are only supported by JAWS 10 public beta. 2. Landmark roles are supported by FF3 only as of this writing. Does anyone know if support for these roles in IE8 is forthcoming? 3. What is the purpose of this role vs HTML tags such as headings? 4. What do these roles map to in MSAA, IA2 and ATK? 5. Are these roles worth of investing into?
I think landmakrs are (or will become once better supported) a very useful ARIA "feature".
Headings are certainly a way of achieving a similar effect, but they were never meant as role identifiers. They work because people have learned to use them to "label" points on the page. I believe they were originally conceived as ways of marking up true section identifiers within text documents (chapter 1, section 1.1.2, etc).
Consider a page with two levels of navigation, one across the top, and another just underneath that. I'm not interested in whether this is a visually appealing way of setting things up; its just easy to describe in words. We could think of the lower row of controls as a subnav. THis will change depending on which page we're on, so we want the user to be able to find all elements here, so that useful controls won't be missed.
If we used headings to mark things up, which elements would we hang the headings from? How will the user know which elements are contained within the global nav (the upper one) and which are in the subnav?
If landmakrs were used, and the screen reader were able to move through them as it can through headings, then we could press one key and hear the next landmark, and be moved to that point in the document. We'd know if we reached a subnav, main nav, content area, etc.
In the current jaws implementation, you could use place markers to attach keys to the landmark strings (is there a key to move from one placemarker string to the next - can't remember because I use placemarkers so rarely).
----- Original Message ----- From: "Victor Tsaran" <vtsa...@yahoo.com>
Newsgroups: mozilla.dev.accessibility To: <dev-accessibil...@lists.mozilla.org> Sent: Friday, October 03, 2008 4:47 PM Subject: Landmark roles and their usefulness
Hello all, What are your thoughts around landmark roles? Couple of comments and questions: 1. As of now, landmark roles are only supported by JAWS 10 public beta. 2. Landmark roles are supported by FF3 only as of this writing. Does anyone know if support for these roles in IE8 is forthcoming? 3. What is the purpose of this role vs HTML tags such as headings? 4. What do these roles map to in MSAA, IA2 and ATK? 5. Are these roles worth of investing into?
> 1. As of now, landmark roles are only supported by JAWS 10 > public beta.
hopefully, this situation will change soon -- i will check the orca bugzilla to ascertain if support for navigating between landmark roles is logged as a bug;
> 2. Landmark roles are supported by FF3 only as of this writing. > Does anyone know if support for these roles in IE8 is forthcoming?
i have no direct knowledge, but if the AIA information (such as it is) is correct, then IE8 SHOULD support landmark roles (if anyone from AIA wants to comment on this, PLEASE do -- is it on the ToDo list?)
> 3. What is the purpose of this role vs HTML tags such as headings?
these roles allow finer tuning -- moreover, they allow for repair to pages which use generic elements such as DIV and SPAN to contain, for example, a form comprised of actual form controls, links and javascripted objects (such as the submit button -- a model which is VERY frequently found on the web these days) -- if all that comprises such a search functionality is contained within a DIV, then that DIV should be marked as role="search" so that a user seeking the search functionality on a page can find it and navigate to it directly, as well as providing a virtual FIELDSET for the ersatz/hybrid form
> 5. Are these roles worth of investing into?
yes, yes, and YES -- for HTML, XHTML and XML -- the XHTML Roles Module can be plugged into any extensible language, and the XHTML Access Module provides a means of navigating by role as well as the ability to assign an access element to a role or list of roles - consult:
XHTML Vocabulary Namespace (contains definitions of roles - VERY human readable and a very highly recommended resource) http://www.w3.org/1999/xhtml/vocab/
i hope this helps, gregory. ---------------------------------------------------------------- CONSERVATIVE, n. A statesman who is enamored of existing evils, as distinguished from the Liberal, who wishes to replace them with others. -- Ambrose Bierce, _The Devil's Dictionary_ ---------------------------------------------------------------- Gregory J. Rosmaita, oedi...@hicom.net Camera Obscura: http://www.hicom.net/~oedipus/index.html ----------------------------------------------------------------
---------- Original Message ----------- From: Victor Tsaran <vtsa...@yahoo.com> To: dev-accessibil...@lists.mozilla.org Sent: Fri, 03 Oct 2008 13:47:26 -0700 Subject: Landmark roles and their usefulness
> Hello all, > What are your thoughts around landmark roles? > Couple of comments and questions:
Additionally, note that in comparison to the various states and eventing related bits, it takes relatively little to support landmark roles --- at some level, you could support landmark roles with the browser only needing to make sure that it doesn't drop the role attribute on the floor.
Gregory J. Rosmaita writes:
> > 1. As of now, landmark roles are only supported by JAWS 10 > > public beta. > > hopefully, this situation will change soon -- i will check the orca > bugzilla to ascertain if support for navigating between landmark roles > is logged as a bug; > > > 2. Landmark roles are supported by FF3 only as of this writing. > > Does anyone know if support for these roles in IE8 is forthcoming? > > i have no direct knowledge, but if the AIA information (such as it is) > is correct, then IE8 SHOULD support landmark roles (if anyone from AIA > wants to comment on this, PLEASE do -- is it on the ToDo list?) > > > 3. What is the purpose of this role vs HTML tags such as headings? > > these roles allow finer tuning -- moreover, they allow for repair to > pages which use generic elements such as DIV and SPAN to contain, > for example, a form comprised of actual form controls, links and > javascripted objects (such as the submit button -- a model which is > VERY frequently found on the web these days) -- if all that comprises > such a search functionality is contained within a DIV, then that DIV > should be marked as role="search" so that a user seeking the search > functionality on a page can find it and navigate to it directly, as > well as providing a virtual FIELDSET for the ersatz/hybrid form > > > 5. Are these roles worth of investing into? > > yes, yes, and YES -- for HTML, XHTML and XML -- the XHTML Roles Module > can be plugged into any extensible language, and the XHTML Access Module > provides a means of navigating by role as well as the ability to assign > an access element to a role or list of roles - consult: > > http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080820/ > http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080820/#A_order > http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080820/#A_targetrole > > as well as: > > http://www.w3.org/TR/xhtml-role/ > > and > > XHTML Vocabulary Namespace (contains definitions of roles - VERY human > readable and a very highly recommended resource) > http://www.w3.org/1999/xhtml/vocab/ > > i hope this helps, gregory. > ---------------------------------------------------------------- > CONSERVATIVE, n. A statesman who is enamored of existing evils, > as distinguished from the Liberal, who wishes to replace them > with others. -- Ambrose Bierce, _The Devil's Dictionary_ > ---------------------------------------------------------------- > Gregory J. Rosmaita, oedi...@hicom.net > Camera Obscura: http://www.hicom.net/~oedipus/index.html > ---------------------------------------------------------------- > >
> ---------- Original Message ----------- > From: Victor Tsaran <vtsa...@yahoo.com> > To: dev-accessibil...@lists.mozilla.org > Sent: Fri, 03 Oct 2008 13:47:26 -0700 > Subject: Landmark roles and their usefulness
> > Hello all, > > What are your thoughts around landmark roles? > > Couple of comments and questions:
> > Thanks, > > Victor > > _______________________________________________ > > dev-accessibility mailing list > > dev-accessibil...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-accessibility > ------- End of Original Message -------
Some of these roles should also have potential usefulness for small devices. The most useful are probably role="navigation", role="search" and role="main".
Eventually, HTML plans to create some new elements such as <article> to make it more likely that developers will actually use these semantics.
But, for now, the landmarks are what we have. If a company likes Yahoo! uses them then it will help push the screen reader vendors to support them better. Things are moving forward, but let's just say that we can only get so far through nagging, funding, motivational speeches, etc. Eventually developers want real-world examples. That gives both them and their users something to sink their teeth into.
Aaron Leventhal wrote: > Some of these roles should also have potential usefulness for small > devices. The most useful are probably role="navigation", role="search" > and role="main".
The definitions of these roles seem to be being gradually changed to be a bit clearer (e.g. making it clearer that banner is for site headers not adverts, though I fear the name may have fatally compromised the reliability of the role and existing tutorials frequently get this wrong.)
But it's still hard to map some of them to real-world situations.
Consider role="search".
The current editor's draft for ARIA says role="search" is "The search tool of a web document" (singular).
1. What happens if a document offers multiple search tools? For example, you might have an online store that sells various categories of goods. A category page (say the "DVDs" category page) might feature both a sitewide search in the header and (later in the document) a category-specific search for DVDs.
2. What happens if a document repeats the same search tool in multiple locations, for example both the header and the footer of the page? This scenario suggests some degree of conflict between aiding discovery of areas of the page and identifying the area of the page currently subject to user interaction.
Ideally, the spec should make it clear what authors should do in these situations.
> Aaron Leventhal wrote: >> Some of these roles should also have potential usefulness for small >> devices. The most useful are probably role="navigation", >> role="search" and role="main".
> The definitions of these roles seem to be being gradually changed to > be a bit clearer (e.g. making it clearer that banner is for site > headers not adverts, though I fear the name may have fatally > compromised the reliability of the role and existing tutorials > frequently get this wrong.)
> But it's still hard to map some of them to real-world situations.
> Consider role="search".
> The current editor's draft for ARIA says role="search" is "The search > tool of a web document" (singular).
> 1. What happens if a document offers multiple search tools? For > example, you might have an online store that sells various categories > of goods. A category page (say the "DVDs" category page) might feature > both a sitewide search in the header and (later in the document) a > category-specific search for DVDs.
> 2. What happens if a document repeats the same search tool in multiple > locations, for example both the header and the footer of the page? > This scenario suggests some degree of conflict between aiding > discovery of areas of the page and identifying the area of the page > currently subject to user interaction.
> Ideally, the spec should make it clear what authors should do in these > situations.
>> 1. What happens if a document offers multiple search tools... >> 2. What happens if a document repeats the same search tool in multiple >> locations...
I think all of them should be given a role of "search". In my opinion, the idea is to make it clear how to separate the content on the page by role, and then give the user tools to find and use that content in as transparent and intuitive manner as possible.
----- Original Message ----- From: "Aaron Leventhal" <aaronlevent...@moonset.net> To: "Benjamin Hawkes-Lewis" <bhawkesle...@googlemail.com>
Cc: <dev-accessibil...@lists.mozilla.org> Sent: Monday, October 06, 2008 3:04 PM Subject: Re: Landmark roles and their usefulness
> Benjamin,
> Do you mind forwarding your comments to wai-xtech so they get addressed > by PFWG?
> - Aaron
> On 10/6/2008 7:50 PM, Benjamin Hawkes-Lewis wrote: >> Aaron Leventhal wrote: >>> Some of these roles should also have potential usefulness for small >>> devices. The most useful are probably role="navigation", >>> role="search" and role="main".
>> The definitions of these roles seem to be being gradually changed to >> be a bit clearer (e.g. making it clearer that banner is for site >> headers not adverts, though I fear the name may have fatally >> compromised the reliability of the role and existing tutorials >> frequently get this wrong.)
>> But it's still hard to map some of them to real-world situations.
>> Consider role="search".
>> The current editor's draft for ARIA says role="search" is "The search >> tool of a web document" (singular).
>> 1. What happens if a document offers multiple search tools? For >> example, you might have an online store that sells various categories >> of goods. A category page (say the "DVDs" category page) might feature >> both a sitewide search in the header and (later in the document) a >> category-specific search for DVDs.
>> 2. What happens if a document repeats the same search tool in multiple >> locations, for example both the header and the footer of the page? >> This scenario suggests some degree of conflict between aiding >> discovery of areas of the page and identifying the area of the page >> currently subject to user interaction.
>> Ideally, the spec should make it clear what authors should do in these >> situations.
in the case of multiple search functions in a document instance, one would use the "lebelledby" ARIA property to distinguish "search form 1" from "search form 2" -- so that the user has a choice of search interfaces:
* "Search Mozilla Accessibility space:" * "Keyword Search for dev-accessibility mailing list archive"
etc. -- the generic roles defined in the XHTML Role Module and reused in ARIA are just that -- generic -- it is up to the author to correctly label each and every instance of a repeat role, just as it is the author's responsibility to label each and every item assigned a role (and, in ultra-good-practice, those that aren't)
as for repeated search functions with identical purposes, the user should have the option of suppressing multiple instances of
role="search" labelledby="foo"
or having them each listed in a list of roles or a list of targetroles -- the important thing is labelling, and consistent labelling of identical items with identical labels (such as the case in which an identical search interface appears at the top of the document's order as well as at the end...
gregory. ------------------------------------------------------- lex parsimoniae: * entia non sunt multiplicanda praeter necessitatem. ------------------------------------------------------- the law of succinctness: * entities should not be multiplied beyond necessity. ------------------------------------------------------- Gregory J. Rosmaita, oedi...@hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ -------------------------------------------------------
---------- Original Message ----------- From: "Rich Caloggero" <r...@MIT.EDU> To: "Aaron Leventhal" <aaronlevent...@moonset.net>, "Benjamin Hawkes-
Lewis" <bhawkesle...@googlemail.com> Cc: dev-accessibil...@lists.mozilla.org Sent: Mon, 6 Oct 2008 16:49:25 -0400 Subject: Re: Landmark roles and their usefulness
> >> 1. What happens if a document offers multiple search tools... > >> 2. What happens if a document repeats the same search tool in multiple > >> locations...
> I think all of them should be given a role of "search". In my > opinion, the idea is to make it clear how to separate the > content on the page by role, and then give the user tools to > find and use that content in as transparent and intuitive manner > as possible.
> -- Rich
> ----- Original Message ----- > From: "Aaron Leventhal" <aaronlevent...@moonset.net> > To: "Benjamin Hawkes-Lewis" <bhawkesle...@googlemail.com> > Cc: <dev-accessibil...@lists.mozilla.org> > Sent: Monday, October 06, 2008 3:04 PM > Subject: Re: Landmark roles and their usefulness
> > Benjamin,
> > Do you mind forwarding your comments to wai-xtech so they get addressed > > by PFWG?
> > - Aaron
> > On 10/6/2008 7:50 PM, Benjamin Hawkes-Lewis wrote: > >> Aaron Leventhal wrote: > >>> Some of these roles should also have potential usefulness for small > >>> devices. The most useful are probably role="navigation", > >>> role="search" and role="main".
> >> The definitions of these roles seem to be being gradually changed to > >> be a bit clearer (e.g. making it clearer that banner is for site > >> headers not adverts, though I fear the name may have fatally > >> compromised the reliability of the role and existing tutorials > >> frequently get this wrong.)
> >> But it's still hard to map some of them to real-world situations.
> >> Consider role="search".
> >> The current editor's draft for ARIA says role="search" is "The search > >> tool of a web document" (singular).
> >> 1. What happens if a document offers multiple search tools? For > >> example, you might have an online store that sells various categories > >> of goods. A category page (say the "DVDs" category page) might feature > >> both a sitewide search in the header and (later in the document) a > >> category-specific search for DVDs.
> >> 2. What happens if a document repeats the same search tool in multiple > >> locations, for example both the header and the footer of the page? > >> This scenario suggests some degree of conflict between aiding > >> discovery of areas of the page and identifying the area of the page > >> currently subject to user interaction.
> >> Ideally, the spec should make it clear what authors should do in these > >> situations.
