This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13549 - 4.10.18 associating form elements with forms that do not contain them can cause navigation problems for AT and keyboard users
Summary: 4.10.18 associating form elements with forms that do not contain them can cau...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML a11y Task Force (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Cynthia Shelly
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard:
Keywords: a11y, a11ytf
Depends on:
Blocks:
 
Reported: 2011-08-03 01:12 UTC by Cynthia Shelly
Modified: 2014-03-08 21:34 UTC (History)
8 users (show)

See Also:

Attachments

Description Cynthia Shelly 2011-08-03 01:12:28 UTC 
What is the use case for associating a form element with a differnt form than the one that contains it?  The spec says this is to work around lack of support for nested forms, but what is the use case for nested forms?

When an element is associated with a different form than the one that contains it, it will cause behavior that the user will not expect.  This will be particularly problematic for screen reader users, because the screen reader reading order follows the DOM order, not the specified form relationships.  Similarly, without significant work by authors, keyboard tab order will not match either.  

This feature seems likely to introduce author errors, without clear benefit.  Instead, nested forms should be considered an author error.  Browser behavior for handling this error can be specified, but we should not add features to handle it.
Comment 1 Michael[tm] Smith 2011-08-04 05:04:07 UTC 
mass-moved component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-08-11 03:01:18 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The use case is situations like tables where each column or each row contains a different form, and cases where a page-long form contains inside it a separate unrelated form (e.g. a tax form with a little calculator on the side to help work out some component of the bigger form).

I don't really see how it would be confusing. The user has no idea what the DOM looks like, realistically speaking.
Comment 3 Cynthia Shelly 2011-12-16 23:54:04 UTC 
screen reader users do know what the DOM order is, because screen readers present content in DOM order, not visual order.  So, these use cases will become confusing for these users.

Similarly, tab order is based on DOM order.  It can be adjusted with incrementing tabindexes, but that is a strategy that is well known to get broken over time, and also difficult to implement in dynamic and composited sites.  

Wouldn't it make sense in the use cases below to just use one big form, around all the elements?  This feature seems to encourage overly complex and inaccessible authoring practices, when we should be developing techniques to avoid that.
Comment 4 Cynthia Shelly 2011-12-16 23:55:25 UTC 
Can you link to some examples of those use cases, so we can see if there is a way to build them accessiblity, and build them without this feature?
Comment 5 Ian 'Hixie' Hickson 2012-01-13 00:50:11 UTC 
There's definitely ways to build them without this feature. Just have the server check which button was pressed, and act accordingly, or put the forms after each other. That's what people do now (e.g. this very page does that — it has the bug form in the middle and search forms at the top and bottom). It makes maintenance difficult. Sometimes people split the other form into an entirely separate page, e.g. the way that the "Add an attachment" feature above opens a separate page instead of being done inline.

I don't see why the form="" feature would have any implications on accessibility. Users already have to deal with content intermixed with other content (e.g. ads, sidebars, etc). There's nothing particularly special about AT users here — visual users have to deal with pages with mixed content too.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: no new information since comment 2
Comment 6 Mark Sadecki 2014-03-08 21:34:36 UTC 
Discussed in HTML Accessibility TF Meeting on 13 Feb 2014
http://www.w3.org/2014/02/13-html-a11y-minutes.html#item05

RESOLVED to consider for HTML 5.1

Moved to HTML a11y Task Force component on 08 MAR 2014 for additional info.