I would also argue that, today, navigating a web page should be by regional landmarks first. They create a table of contents for the page and we advise all IBM developers to ensure all content is contained within a landmark. This way content is not orphaned. To that end a form should be treated as a landmark and should appear in the table of contents used for navigation by ATVs.
We are way beyond one off landmarks (just a form) and starting with heading navigation today. Rich Rich Schwerdtfeger > On Aug 25, 2016, at 10:51 AM, Rich Schwerdtfeger <richsch...@gmail.com> wrote: > > Well it is used by the most pervasive apps on the planet using IA2 already. > Chrome, FF, and eclipse-based apps. > > Sent from my iPhone > > On Aug 25, 2016, at 10:45 AM, Alexander Surkov <surkov.alexan...@gmail.com > <mailto:surkov.alexan...@gmail.com>> wrote: > >> I definitely agree that IA2 needs a flexible mechanism to expose roles, I'm >> just not sure it should be xml-roles object attribute. >> >> On Thu, Aug 25, 2016 at 11:15 AM, Rich Schwerdtfeger <richsch...@gmail.com >> <mailto:richsch...@gmail.com>> wrote: >> Alex, those object attributes should have been included in IA2 a long time >> ago. I in no way see these as a hack. Eclipse uses them too. >> >> Sent from my iPhone >> >> On Aug 25, 2016, at 9:49 AM, Alexander Surkov <surkov.alexan...@gmail.com >> <mailto:surkov.alexan...@gmail.com>> wrote: >> >>> This is true, however xml-roles is not standard attribute in IA2, it's >>> rather a browser specific hack to expose the semantics, that otherwise was >>> missed. So if the API provides a way to expose an element semantics more >>> fully, then I'd say it's the way to go. >>> >>> Having said that, I'm also concerned about backward-compatibility issue. >>> >>> On Thu, Aug 25, 2016 at 10:37 AM, Joanmarie Diggs <jdi...@igalia.com >>> <mailto:jdi...@igalia.com>> wrote: >>> Sorry for being spammy, but with respect to the loss of semantics: The >>> type of landmark is still being exposed via object attribute. So I'll >>> still know if an ATK_ROLE_LANDMARK is a form, or navigation, or .... >>> >>> On 08/25/2016 10:24 AM, Joanmarie Diggs wrote: >>> > Hi Alex, all. >>> > >>> > I don't recall saying "kill the form role" in ATK. We have no plans to >>> > deprecate ATK_ROLE_FORM. Instead, I believe I said something along the >>> > lines of the following: >>> > >>> > Q: Should HTML's form element be treated like a landmark for the >>> > purposes of navigation? >>> > >>> > If Yes: Map it to ATK_ROLE_LANDMARK >>> > If No: Continue mapping it to ATK_ROLE_FORM >>> > >>> > --joanie >>> > >>> > On 08/25/2016 10:08 AM, Alexander Surkov wrote: >>> >> I don't think Jamie argues that FORM is not a landmark. The point is >>> >> that FORM is a form and also a landmark. IA2 provides a special FORM >>> >> role, which is used both for ARIA and HTML currently, and adopted by >>> >> browsers and screen readers. >>> >> >>> >> If we use weaker role for forms, then we loose semantics as Jamie >>> >> pointed out, and we make a not backward compatible change. All JAWS and >>> >> other commercial screen reader users will have to buy a new screen >>> >> reader version. >>> >> >>> >> ATK gained this role, because it doesn't have a mechanism to fetch all >>> >> landmarks on a page other than query it by role. And thus they are ok to >>> >> sacrifice ATK form role for performance reasons I think. Note, ATK world >>> >> doesn't have so acute problem of backward compatibility as IA2 has, so >>> >> they have a larger room for changes. IA2 landmark role is a ATK toll to >>> >> keep IA2 compatible with, this is a primary reason, if I do understand >>> >> that right. However I'm not confident too that we should take ATK path >>> >> and kill a form role too. >>> >> >>> >> On Thu, Aug 25, 2016 at 3:34 AM, Schnabel, Stefan >>> >> <stefan.schna...@sap.com <mailto:stefan.schna...@sap.com> >>> >> <mailto:stefan.schna...@sap.com <mailto:stefan.schna...@sap.com>>> wrote: >>> >> >>> >> Hi James,____ >>> >> >>> >> __ __ >>> >> >>> >> currently Jaws treats forms like regions as landmarks, i.e. showing >>> >> them in its landmarks dialog, too. They do this for reason, page >>> >> structure is very clearly revealed by this. I consider this as a >>> >> strong feature and do not like this changed.____ >>> >> >>> >> __ __ >>> >> >>> >> The logic behind that is the pragmatic thinking that forms are >>> >> landmark-like, too. And a “navigation” landmark can contain fairly >>> >> complex content, too, not just a list of links.____ >>> >> >>> >> __ __ >>> >> >>> >> Best Regards____ >>> >> >>> >> Stefan____ >>> >> >>> >> __ __ >>> >> >>> >> *From:*James Teh [mailto:ja...@nvaccess.org >>> >> <mailto:ja...@nvaccess.org> >>> >> <mailto:ja...@nvaccess.org <mailto:ja...@nvaccess.org>>] >>> >> *Sent:* Donnerstag, 25. August 2016 00:33 >>> >> *To:* Rich Schwerdtfeger <richsch...@gmail.com >>> >> <mailto:richsch...@gmail.com> >>> >> <mailto:richsch...@gmail.com <mailto:richsch...@gmail.com>>> >>> >> *Cc:* Alexander Surkov <surkov.alexan...@gmail.com >>> >> <mailto:surkov.alexan...@gmail.com> >>> >> <mailto:surkov.alexan...@gmail.com >>> >> <mailto:surkov.alexan...@gmail.com>>>; Joseph Scheuhammer >>> >> <cl...@alum.mit.edu <mailto:cl...@alum.mit.edu> >>> >> <mailto:cl...@alum.mit.edu <mailto:cl...@alum.mit.edu>>>; Joanmarie Diggs >>> >> <jdi...@igalia.com <mailto:jdi...@igalia.com> >>> >> <mailto:jdi...@igalia.com <mailto:jdi...@igalia.com>>>; IA2 List >>> >> <accessibility-...@lists.linux-foundation.org >>> >> <mailto:accessibility-...@lists.linux-foundation.org> >>> >> <mailto:accessibility-...@lists.linux-foundation.org >>> >> <mailto:accessibility-...@lists.linux-foundation.org>>>; ARIA Working >>> >> Group <public-a...@w3.org <mailto:public-a...@w3.org> >>> >> <mailto:public-a...@w3.org <mailto:public-a...@w3.org>>>; Steven >>> >> Faulkner <faulkner.st...@gmail.com <mailto:faulkner.st...@gmail.com> >>> >> <mailto:faulkner.st...@gmail.com <mailto:faulkner.st...@gmail.com>>> >>> >> *Subject:* Re: [Accessibility-ia2] IA2 Role Landmark____ >>> >> >>> >> __ __ >>> >> >>> >> Hi Rich,____ >>> >> >>> >> __ __ >>> >> >>> >> I understand the reason for the use of the landmark role for >>> >> role="form". However, I disagree with the HTML form element being >>> >> mapped to the landmark role because semantics are lost. The fact >>> >> that something is a form has more semantic value than just being a >>> >> landmark. Still, if the spec already requires this, I guess we have >>> >> little choice but to comply at this stage.____ >>> >> >>> >> >>> >> Jamie____ >>> >> >>> >> On 25/08/2016 3:08 AM, Rich Schwerdtfeger wrote:____ >>> >> >>> >> Jamie, ____ >>> >> >>> >> __ __ >>> >> >>> >> The point is we want ALL the landmarks to be treated the same >>> >> way for ATVs. So, first we determine that it is a landmark. Then >>> >> we go to xml-roles to determine the type of landmark. ____ >>> >> >>> >> __ __ >>> >> >>> >> Otherwise, we need a special case for a form. That is what we >>> >> are trying to avoid. For these reasons ATK/ATSPI created a >>> >> landmark role first. ____ >>> >> >>> >> __ __ >>> >> >>> >> The HTML the form element now uses the ARIA mappings for the >>> >> form role. See "Use WAI-ARIA mapping” under the form element. >>> >> This is for all platforms.____ >>> >> >>> >> __ __ >>> >> >>> >> https://rawgit.com/w3c/aria/master/html-aam/html-aam.html >>> >> <https://rawgit.com/w3c/aria/master/html-aam/html-aam.html> >>> >> <https://rawgit.com/w3c/aria/master/html-aam/html-aam.html >>> >> <https://rawgit.com/w3c/aria/master/html-aam/html-aam.html>>____ >>> >> >>> >> __ __ >>> >> >>> >> We do understand that non-browser applications may still use the >>> >> older Form role mapping as would older browser versions. It is >>> >> for these reasons that our definition of deprecation is that it >>> >> has not gone a way but rather it is going to this new preferred >>> >> mapping. ____ >>> >> >>> >> __ __ >>> >> >>> >> Best,____ >>> >> >>> >> __ __ >>> >> >>> >> Rich____ >>> >> >>> >> __ __ >>> >> >>> >> __ __ >>> >> >>> >> __ __ >>> >> >>> >> Rich Schwerdtfeger____ >>> >> >>> >> __ __ >>> >> >>> >> __ __ >>> >> >>> >> __ __ >>> >> >>> >> On Aug 23, 2016, at 7:35 PM, James Teh <ja...@nvaccess.org >>> >> <mailto:ja...@nvaccess.org> >>> >> <mailto:ja...@nvaccess.org <mailto:ja...@nvaccess.org>>> >>> >> wrote:____ >>> >> >>> >> __ __ >>> >> >>> >> If you believe that role="form" has no semantic value other >>> >> than being a landmark, then let's go ahead and map it to >>> >> IA2_ROLE_LANDMARK. On the other hand, the HTML form tag >>> >> *does* have semantic value other than being a landmark, so >>> >> I'd argue it should be IA2_ROLE_FORM.____ >>> >> >>> >> __ __ >>> >> >>> >> On 24/08/2016 5:22 AM, Rich Schwerdtfeger wrote:____ >>> >> >>> >> We are not asking that IA2_ROLE_FORM be deprecated >>> >> altogether. Even with ARIA we have some attributes that >>> >> re deprecated but that is meant so that there will be a >>> >> replacement solution. An example is the drag and drop >>> >> aria properties. For ARIA browser conformance testing to >>> >> exit Candidate Recommendation we will be testing for >>> >> IA2_ROLE_LANDMARK on form roles. ____ >>> >> >>> >> __ __ >>> >> >>> >> Rich Schwerdtfeger____ >>> >> >>> >> __ __ >>> >> >>> >> __ __ >>> >> >>> >> __ __ >>> >> >>> >> On Aug 18, 2016, at 9:56 PM, James Teh >>> >> <ja...@nvaccess.org <mailto:ja...@nvaccess.org> >>> >> <mailto:ja...@nvaccess.org <mailto:ja...@nvaccess.org>>> >>> >> wrote:____ >>> >> >>> >> __ __ >>> >> >>> >> On 11/08/2016 2:58 AM, Alexander Surkov wrote: >>> >> >>> >> ____ >>> >> >>> >> 1) adding IA2_ROLE_LANDMARK and____ >>> >> >>> >> Yes. >>> >> >>> >> >>> >> ____ >>> >> >>> >> 2) deprecating IA2_ROLE_FORM?____ >>> >> >>> >> I'd argue that there is more semantic value in a >>> >> "form" than just the fact that it is a landmark. >>> >> This probably doesn't apply to ARIA (at least for >>> >> now), since role="form" is defined as only a >>> >> landmark. However, I'd argue it does apply to the >>> >> HTML form tag. So, I'm fine t not use IA2_ROLE_FORM >>> >> for ARIA role="form", but I'm dubious about >>> >> deprecating it altogether, including for the HTML >>> >> form tag. >>> >> Jamie >>> >> >>> >> -- >>> >> James Teh >>> >> Executive Director, NV Access Limited >>> >> Ph +61 7 3149 3306 <tel:%2B61%207%203149%203306> >>> >> <tel:%2B61%207%203149%203306 <tel:%2B61%207%203149%203306>> >>> >> www.nvaccess.org <http://www.nvaccess.org/> >>> >> <http://www.nvaccess.org/ <http://www.nvaccess.org/>> >>> >> Facebook: http://www.facebook.com/NVAccess >>> >> <http://www.facebook.com/NVAccess> >>> >> <http://www.facebook.com/NVAccess >>> >> <http://www.facebook.com/NVAccess>> >>> >> Twitter: @NVAccess >>> >> SIP: ja...@nvaccess.org <mailto:ja...@nvaccess.org> >>> >> <mailto:ja...@nvaccess.org <mailto:ja...@nvaccess.org>>____ >>> >> >>> >> __ __ >>> >> >>> >> >>> >> >>> >> ____ >>> >> >>> >> -- ____ >>> >> >>> >> James Teh____ >>> >> >>> >> Executive Director, NV Access Limited____ >>> >> >>> >> Ph +61 7 3149 3306 <tel:%2B61%207%203149%203306> >>> >> <tel:%2B61%207%203149%203306 <tel:%2B61%207%203149%203306>>____ >>> >> >>> >> www.nvaccess.org <http://www.nvaccess.org/> >>> >> <http://www.nvaccess.org/ <http://www.nvaccess.org/>>____ >>> >> >>> >> Facebook: http://www.facebook.com/NVAccess >>> >> <http://www.facebook.com/NVAccess> >>> >> <http://www.facebook.com/NVAccess >>> >> <http://www.facebook.com/NVAccess>>____ >>> >> >>> >> Twitter: @NVAccess____ >>> >> >>> >> SIP: ja...@nvaccess.org <mailto:ja...@nvaccess.org> >>> >> <mailto:ja...@nvaccess.org <mailto:ja...@nvaccess.org>>____ >>> >> >>> >> __ __ >>> >> >>> >> >>> >> >>> >> ____ >>> >> >>> >> -- ____ >>> >> >>> >> James Teh____ >>> >> >>> >> Executive Director, NV Access Limited____ >>> >> >>> >> Ph +61 7 3149 3306 <tel:%2B61%207%203149%203306> >>> >> <tel:%2B61%207%203149%203306 <tel:%2B61%207%203149%203306>>____ >>> >> >>> >> www.nvaccess.org <http://www.nvaccess.org/> <http://www.nvaccess.org >>> >> <http://www.nvaccess.org/>>____ >>> >> >>> >> Facebook: http://www.facebook.com/NVAccess >>> >> <http://www.facebook.com/NVAccess> <http://www.facebook.com/NVAccess >>> >> <http://www.facebook.com/NVAccess>>____ >>> >> >>> >> Twitter: @NVAccess____ >>> >> >>> >> SIP: ja...@nvaccess.org <mailto:ja...@nvaccess.org> >>> >> <mailto:ja...@nvaccess.org <mailto:ja...@nvaccess.org>>____ >>> >> >>> >> >>> > >>> > _______________________________________________ >>> > Accessibility-ia2 mailing list >>> > Accessibility-ia2@lists.linuxfoundation.org >>> > <mailto:Accessibility-ia2@lists.linuxfoundation.org> >>> > https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 >>> > <https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2> >>> > >>> >>> >>
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
