- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 8 Apr 2013 11:44:03 +0100
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: Alastair Campbell <alastc@gmail.com>, WAI Interest Group <w3c-wai-ig@w3.org>
- Message-ID: <CA+ri+VkpnVvkfCbJ1gN3a_998PCiw1Wg62wrtCD71vqyCw9DmQ@mail.gmail.com>
browser have logic that assigns platform API roles to elements by default, they also have logic that assigns any role values declared inline to the platform API, overriding the default platform API role for the element, they don't have default ARIA roles assigned for each element. -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 8 April 2013 11:32, Patrick H. Lauke <redux@splintered.co.uk> wrote: > On 08/04/2013 11:17, Steve Faulkner wrote: > >> I don't think that this is being held back by lack of access. >> >> the mapping between html elements and landmark roles is specified, it >> would be trivial (or just as trivial) to look for an element name as an >> role value no? >> > > Sure, but it feels wrong. If browsers have internal logic that assigns > roles automatically for defaults, why not expose that via object > properties? As it stands, I'd have to look for BOTH existence of, say, > <main> AND any arbitrary element that's been blessed with role="main". If > <main> internally already gets assigned the equivalent of role="main" > anyway, it would be great to have this exposed transparently, so my script > just needs to look for anything that has that role property, without > special casing. > > > P > -- > Patrick H. Lauke > ______________________________**______________________________**__ > re·dux (adj.): brought back; returned. used postpositively > [latin : re-, re- + dux, leader; see duke.] > > www.splintered.co.uk | www.photographia.co.uk > http://redux.deviantart.com | http://flickr.com/photos/**redux/<http://flickr.com/photos/redux/> > ______________________________**______________________________**__ > twitter: @patrick_h_lauke | skype: patrick_h_lauke > ______________________________**______________________________**__ >
Received on Monday, 8 April 2013 10:45:13 UTC