1

I have a legacy Web Application Project (WAP) that I need to ensure is accessible. This type of project has a Master Page (Site.Master) and each page (called a Web Form) inherits from that page to maintain a consistent look.

A fresh Master Page looks like below:

<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Site.master.cs" Inherits="First5Edmx.Site" %>

<!DOCTYPE html>

<html>
<head runat="server">
    <title></title>
    <asp:ContentPlaceHolder ID="head" runat="server">
    </asp:ContentPlaceHolder>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
        
        </asp:ContentPlaceHolder>
    </div>
    </form>
</body>
</html>

You will see that the body contains a form tag, which means that every page using Site.Master as it's template will have a form on it, regardless of if it's actually a form. If you remove the form tag the project will not compile.

When I run web accessibility on my site I am getting the error "The page contains a form but there is no submit button" on every page. It is, of course, correct, but how do I make this code accessible (without re-creating the whole project in more modern technology)?

Dharman
  • 30,962
  • 25
  • 85
  • 135
Laura Thomas
  • 43
  • 6
  • Depending on your usage, you might not be able to remove it if for example your are using server controls that require such form. You can try setting `<%@ EnablesViewState="false" %>` and removing it but some other parts of your web application may become unusable. – Canica Aug 27 '19 at 20:44
  • When asking about error messages, try to include the name of the tool you used, and provide the exact message it gives you. – andrewmacpherson Sep 08 '19 at 08:21

2 Answers2

2

Whether or not you can make the warning disappear, remember that validators and checkers are there only to draw your attention to potential problems, but not every single message may not necessarily be a real problem. It's especially true with accessibility checkers. They globally make good assumptions, but sometimes can't know between a misstake and something a bit odd but desired for whatever reason.

The most important with such tools is that, if you have a warning that you can't/don't want to fix, is to exactly know what it implies. If you can live with the implications, then you can live with the warning. To know what it implies exactly, the best is of course to make manual tests. Accessibility tools can never replace manual tests.

Coming back to your particular case, of course the tool is technically correct: a form must have a submit button. In practice however, if a form has neither any field nor any button, it's impossible to send anything. So there will only be very few annoyance for you and for the user, if any.

You can still try two things in the pages having no real form, though:

  • Add the role="presentation" to the <form> as suggested in the other answer, so that screen readers won't announce a form to the user when there's nothing to fill
  • Add a dummy submit button, disabled and hidden with display:none so that no one can see nor click it, if you really want to make the accessibility checker happy. Note that it may cause trouble to users with custom or disabled CSS. OF course there shouldn't be any additional submit button when there's already a real one.

Think about the second item: what do you prefer ? a warnings in your tool, or a little hacky solution potentially causing trouble to 1 user out of 1000000 and maybe a few buggy pages if by misstake you leave the normal and a dummy button ? Now that you know what the consequences might be, personally I think that it isn't worth the effort to clear the warning just to say that you ahve done it, but do as you feel it.

The role=presentation has no side effect when not using a screen reader, so you are totally safe on this one.

QuentinC
  • 12,311
  • 4
  • 24
  • 37
  • Good answer. I like the way you emphasize that we're trying to help people, not satisfy our tools. The presntation role is intended for cases like this. The dummy button is a risky suggestion, but your answer points out it's flaws. – andrewmacpherson Sep 08 '19 at 08:19
-2

I'm not sure if this will still be flagged by the compiler, or whatever is throwing the error, but you can hide elements with display:none. This will also hide it from assistive tech, so if there's a tool that's flagging this as an issue, hiding it might prevent it from being flagged.

You can also try role="presentation" which basically tells assisitve tech that this element is solely for visual purposes and contains no information. It's a bit of a hack, but worth a try.

<form style="display:none" id="form1" runat="server">
    <div>
        <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">

        </asp:ContentPlaceHolder>
    </div>
    </form>
Taylor N
  • 500
  • 1
  • 3
  • 15
  • The web accessibility checker will still raise the error since the `
    ` tag semantics means it expects a form regardless of it being hidden.
     – Canica Aug 27 '19 at 20:39
  • 1
    Thank you for your suggestions. display:none hid the whole page (since the content is within the form tag. Role='presentation' didn't do anything different. – Laura Thomas Aug 27 '19 at 21:31
  • The `display:none` approach won't work. Master pages in ASP.net use a form element as a wrapper for the whole page content, regardless of whether there is anything that a human would call a "form". – andrewmacpherson Sep 08 '19 at 08:04
  • 1
    The part explaining the purpose of the presentation role isn't really accurate. It does NOT mean that the element _contains_ no information. Nor does imply anything about "solely visual". Rather, it means that the element does not have any special semantic purpose of it's own. It is basically equivalent to a `div`. The element's children are considered to be content, which should be presented to all users, and may have semantics of their own. Far from being a hack, the suggestion to use the presntaion role is entirely valid. This is exactly the sort of situation the role us intended for. – andrewmacpherson Sep 08 '19 at 08:14