508 Compliance title attribute vs a hidden absolutely positioned label - css

Is the title attribute ok to use for accesibility when it comes to 508 compliance?
For example:
<style>
#date_box{width:250px; border:2px solid #AAA;}
input{width:100px;}
</style>
<div id="date_box">
<input title="to" type="text" id="to" name="to" />
<label for="from">from</label>
<input type="text" id="from" name="from" />
</div>
Or is it best to do a hidden label with an absolute position and a negative margin?

When a visual label on a control is redundant it is OK to use a title attribute. The accessible name calculation for form controls includes the title attribute content, so it is now it has been in the past and will continue to be a robust method to provide an accessible name for a control in the limted circimstances where a visible label is not required. There is a WCAG 2.0 technqiue that covers this. This article provides test results and discussion on this technique: Title Attributes as Form Control Labels

The Section 508 rule about forms is rather abstract: “(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.”
So the questions here are: If you use a form field without a label, can you ensure that any assistive software gives the user access to the text that is logically a label but placed e.g. into the field as default content and/or in a title attribute? And if you use a label but hide it with CSS, is it sure that any assistive software can still make it available to the user.
I don’t think that anyone can guarantee that for all current and future programs, so it is clearly safest to use a normal label and normal label markup.

Related

Can you use aria-live more than once on a webpage?

I'm creating a from that has validation errors show below the related inputs. To make the form more accessible I have added aria-lives to div that will hold the error message. With having more than one aria-live will this make it worse for the users?
<div
id="awesome-id">
<label for="awesome-id--input">
This is a label
</label>
<input
type="tel"
id="awesome-id--input"
required>
<div
role="region"
aria-live="polite"
id="awesome-id--error-message">
</div>
</div>
<div
id="another-id">
<label for="another-id--input">
This is another label
</label>
<input
type="tel"
id="another-id--input"
required>
<div
role="region"
aria-live="polite"
id="another-id--error-message">
</div>
</div>
You can have multiple aria-live containers - especially since they are “polite”, they should wait until it’s quiet to give you the feedback. Whether this is also a good experience for your users, you should simply test with a screen-reader (or, preferably, conduct user-tests).
However, I would remove the role=“region”. This is the specification of the Region element at MDN Web Docs:
The region role should be reserved for sections of content sufficiently important that users will likely want to navigate to the section easily and to have it listed in a summary of the page.
Landmarks like Region allow the user to quickly navigate to them. But adding all error messages to that list of landmarks would just muddy it in my opinion. Instead you should consider adding role=“alert”.
Also, make sure that the error container having aria-live is present at the page on load - even though it is empty. Otherwise some browsers will not know to listen for changes in it.
Lastly, remember to also toggle aria-invalid=“true/false” on the input to provide the screen-reader with proper feedback.

Why can't I access the value of a hidden input field from my ASP.NET code-behind?

From my page's code-behind I want to access the value of this hidden field. The value is set properly. I confirmed by checking its value.
<div class="hiddenValues">
<input id="HiddenReportId" type="hidden" />
</div>
From my code behind, I'm using the following to access the above input
string id = Request.Form["HiddenReportId"];
When I run the application this line throws a null exception. Any suggestions ? Thanks!
The input needs to be inside of the form tag (which it may be, can't tell from the code snippet). Also, it needs to have a name attribute:
<div class="hiddenValues">
<input id="HiddenReportId" name="HiddenReportId" type="hidden" />
</div>
Its id attribute may be redundant and isn't necessary if you're not using it. But form elements are identified by their name attributes in a POST.
(It feels a bit unintuitive from an ASP.NET perspective to the uninitiated, I know. ASP.NET convention is to identify everything by an ID, but web browsers use name when crafting a POST. And the web browser knows nothing of the server-side technology being used, it follows HTTP standards instead.)

Why are hidden fields considered client side state management?

According to MSDN and the MCTS self-paced training, asp.net can use Hidden fields for client-side state management. The book material goes on to say view-state is more secure than hidden fields because the data is encrypted.
I must be missing something here. I setup a Label and made it hidden. I can store data in this hidden label and it won't even be sent to the client browser. This not only works like server side state (note the runat=server), but this seems more secure than view-state because there's no need for encryption as the client can't even see the field.
<asp:Label ID="Label1" Visible="false" runat="server">secret info</asp:Label>
Contrast this with an HTML input field. Here, the client state info makes sense.
<input id="Text2" type="text" style="visibility:hidden;" value="secret 99" />
So what's the deal?
When you create a label in .net and set it's visibility to Hidden, it does not render to the client and its data is stored in viewstate.
Therefore, it is not "more" secure than viewstate as it is using viewstate to maintain the data.
Regarding hidden fields, there are four kinds: First up is the regular HTML one which is simply an input of type hidden. This has no visible rendering although it is in the html. It also has no viewstate properties. It is declared as:
<input id="MyId" type='hidden' value='whatever' />
The second one is a regular input with a css property marking it as hidden: If CSS is disabled or otherwise overriden then the control would be visible to the user. Other than that its pretty close to the same thing as a type='hidden'.
<input id='MyId' type='text' value='whatever' style='visibility:hidden' />
The third one is the .Net hidden field. This does has viewstate storage, but it also causes a regular hidden field to be generated in the html.
<asp:HiddenField id='MyId' runat='server' value='whatever' />
And, the fourth one is a regular .net text box that is marked as not-visible.
<asp:TextBox id='MyId' runat='server' Text='whatever' Visible='False' />
The .net ones will cause data to be placed in viewstate. The HTML ones do not. If you set Visible=False on a .Net control then it is not rendered to the client however it's data is typically stored in viewstate.
There are other ways of throwing data into the page, but they are derivations of the above.
Generally speaking if you have a value that your javascript code needs but you don't need to display it to the client then you use a hidden field (html or .net). If you have a secret value then typically you don't want this to go to the client side if at all possible. And that means even keeping it out of viewstate. As a side note, don't depend on viewstate "security' there are tools out there which will easily decrypt it.
A field which is not displayed is not a hidden field (even though it is "hidden").
Hidden fields are <input type="hidden" name="somename" value="somevalue" /> fields. And those can be manipulated by users.

Multi language: asp:label aganist html:label with asp:Literal

I'm adding multi language support to a prototype web site. The site was developed using html lables which I could multilanguage using asp:literal or I could change them all to asp:labels as shown below.
<asp:label ID="lblAddress1" runat="server" Text='<%$ Resources:lblAddress1 %>' /></br>
<label><asp:Literal ID="Literal1" runat="server" Text="<%$ Resources:lblAddress1 %>"></asp:Literal></label>
Web stuff isn't my area of expertise and the guys here don't think there is any advantage one way or the other. What would you choose and why?
<asp:Literal>
Use this control as a placeholder for any text you wish to insert in the page. The output will not be wrapped in any html markup tags (simplest).
<asp:Label>
Use this control in the same way as the , however, This control will wrap the text in html tags. These span tags allow the control to have additional properties (css styling etc.) which can be leveraged.
<label>
This html tag has semantic value in a page and is used to associate form elements with their description.
<label for="SaveLoginName">Remember Me:</label>
<input type="checkbox" id="SaveLoginName" />
A browser can use this info to provide additional accessibility features such as enabling clicking text to toggle checkbox value.
Each of these have appropriate usage scenarios.
Seems to be a matter of taste. Although I think the second option may add a little weight to the page because literals are usually wrapped in <span>

What's the Literal control used for and what's the difference to the Label Control in asp.net?

What Literal control is used for in asp.net? and What is the difference between them and Label control?
The major difference is that the Label Control adds the span tag to the text (property) you set, allowing to apply a style to it:
<span>My Label text</span>
The Literal Control allows you to render any kind of content. You can use it to render scripts, hmtl and any other type of document content. It doesn't change the string you provide in the Text property.
Note: the Label control allows you to render straight HTML too, but it puts all your text in span tags as mentioned. So, for rendering large HTML portions a Literal control is the way to go.
P.S.: In HTML there is a <label> tag. If you use the AssociatedControlId property of the Label control, it will render as HTML <label> (thanks to Ray for pointing that out.)
For example:
<asp:Label runat="server" id="FirstNameLabel" AssociatedControlId="FirstNameTextBox">
Input First Name:
</asp:Label>
<asp:Textbox runat="server" id="FirstNameTextBox" />
Will render as:
<label for="FirstNameTextbox" id="FirstNameLabel">Input first name:</label>
<input type="text" id="FirstNameTextbox" name="FirstNameTextBox" />
See also here on W3 Schools.
One thing also to note is if you are justing using it to display something and have no need for formatting the text use a Literal control. The ViewState is not as heavy with a Literal vs a Label control and when you have many of these on a page using ViewState it can really bloat your page size.
I always ask myself, do I need to apply a custom style or formatting? Yes, use a Label. No, use a Literal.
It is used to display text on the page, the text that is displayed can be set at runtime via server side code.
The label control also has the AssociatedControlId property that associates the label with another control. An example of where this is useful is with a textbox control. Once these are associated, screen readers are more able to give better results.
Another example is a radio button with a label allows you to click on the label and the radiobutton will select if the AssociatedControlId property is set.
MSDN on AssoicatedControlId
As splattne mentions, the label encloses its text in a span, whereas the literal is simply a placeholder. However, be careful in making assumptions about how ASP.Net controls are going to render. It can depend on the user agent that you are using. For instance, the panel control renders as a div in IE, but renders as a table with Firefox.
It will place LITERALLY whatever text you place in it on the page. You can use it to write html, JavaScript or just plain text.
We can use literal control in the title tag whereas label cannot be used in the title tag
Label can be used to set focus on other controls like Textbox.
Whereas Literal simply rander the static text on the web page

Resources