Techniques for WCAG 2.0

Skip to Content (Press Enter)

-

SL10: Implementing a Submit-Form Pattern in Silverlight

Applicability

This technique relates to:

User Agent and Assistive Technology Support Notes

See User Agents Supported for general information on user agent support.

Description

The objective of this technique is to declare Silverlight user interface elements related to user input and use the Silverlight two-way data binding techniques to provide a Submit button and opt-in forms submission logic pattern for forms. The Submit button serves as the final deliberate step of a form submission scenario. Silverlight programming techniques do not provide a "Submit button as a distinct object. Rather, application authors design their user input workflow such that it is a single user action that initiates change of context that is related to a data input scenario. The key to doing this in Silverlight is to use a data binding mode that sets UpdateSourceTrigger of all individual databound fields in that form or transaction. For any data binding where the UpdateSourceTrigger is Explicit, no real-time change is made to the data, until the UpdateSource method is called on each of these bindings. The application-specific Submit button is connected to an event handler that calls UpdateSource on all of the databound UI elements that comprise that form.

Validation of data

The Submit button itself can also be the UI element that provides warnings, instructions, etc. in a way that assistive technologies can report to users, through the AutomationProperties techniques. Using a Submit model for Silverlight form input to databound data sources relies on a particular data binding mode. The Submit model can be used either along with client-side or server-side validation techniques. The example does not explicitly include either validation technique.

Examples

Example 1: Two form fields with Submit

In this example, the form fields correspond to a data object that implements a view model. Silverlight uses the view model and data annotations to generate some of its UI, notably the names of the fields are bound to the original view model names from the data. This example has a UI defined in XAML and logic defined in C#. The following is the XAML UI , which also includes the binding definitions. Note the Mode=TwoWay, UpdateSourceTrigger=Explicit attributes in the bindings. This is the binding mode to use for the Submit button scenario.

<UserControl x:Class="BasicSubmitButton.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk">
 <StackPanel x:Name="LayoutRoot" Background="White" Margin="10">
   <Grid>
   <Grid.RowDefinitions>
       <RowDefinition Height="Auto"/>
       <RowDefinition Height="Auto"/>
       <RowDefinition Height="Auto"/>
       <RowDefinition Height="Auto"/>
       <RowDefinition Height="Auto"/>
   </Grid.RowDefinitions>
   <Grid.ColumnDefinitions>
       <ColumnDefinition Width="Auto"/>
       <ColumnDefinition Width="200"/>
       <ColumnDefinition Width="Auto"/>
   </Grid.ColumnDefinitions>
   <TextBlock Text="Form Input" FontSize="16" FontWeight="Bold"
     Grid.Column="1" HorizontalAlignment="Center" />
       <sdk:Label x:Name="NameLabel" Grid.Row="2" Margin="3"
   HorizontalAlignment="Right"
   Target="{Binding ElementName=NameTextBox}"/>
   <TextBox x:Name="NameTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=NameLabel}"
     Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=Explicit}"
     Grid.Column="1" Grid.Row="2" Margin="3" />
       <sdk:Label x:Name="AgeLabel" Grid.Row="3" Margin="3"
   HorizontalAlignment="Right"
   Target="{Binding ElementName=AgeTextBox}"/>
   <TextBox x:Name="AgeTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=AgeLabel}" 
     Text="{Binding Age, Mode=TwoWay, UpdateSourceTrigger=Explicit}"  
     Grid.Column="1" Grid.Row="3" Margin="3" />
   <Button x:Name="SubmitButton" Content="Submit" Click="SubmitButton_Click"
     Grid.Column="1" Grid.Row="4" Width="50" Margin="3"
   AutomationProperties.HelpText="Activate this button to submit form."/>
   </Grid>
 </StackPanel>
</UserControl>

The following is the C# logic for the page. Note the SubmitButton_Click handler. This implementation disables the Submit button (representative of a change of context, because now the form cannot be submitted again) and provides user feedback without performing any validation. The test file included in this technique sets up its data object as a purely client side entity and does no validation, so that no service/server is necessary to use the test file. Each element with a binding calls the UpdateSource method, such that the act of pressing the Submit button commits all the form's information all at once. A full implementation might replace this with a server side data object infrastructure. A full implementation might also provide a "Reset" or "Edit" button to enable form submission again if there were issues.

This example is shown in operation in the working example of Basic Submit Button.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To test UI Automation based behavior such as reading AutomationProperties.HelpText, use Microsoft Windows as platform.

  2. Verify that the user interface design of the form includes a clearly indicated Submit button (a control that adequately communicates to users that activating it will cause input to be submitted and might cause a change of context).

  3. Provide values for the various input fields of the form, and verify that doing so does not in and of itself change the context.

  4. Verify that if change of context occurs at all, that action is delayed until after the Submit button is activated.

Expected Results

#2, #3, and #4 are true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

Techniques are Informative

Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard—not the techniques. For important information about techniques, please see the Understanding Techniques for WCAG Success Criteria section of Understanding WCAG 2.0.