Hour 11: Accessible Apps 1

Overview

In this lesson, you will bring together the concepts you have learned to build an app using the Form library. As you learn how to build apps, you will learn about user interface design and the various kinds of standard controls used by people in practice.

Goals

You have the following goals for this lesson:

• Learn about creating Forms
• Learn about the different kinds of items you can add to Forms
• Build the interface for an app with at least 1 button
• Understand the purpose of user interface design

Warm up

Think about apps or websites you have used in the past. Can you think of examples of apps or sites that were easy or hard to use? What kinds of things made the difference for you between a good or bad experience?

Vocabulary

You will be learning about the following vocabulary words:

Code

You will be using the following new pieces of code:

CSTA Standards

This lesson covers the following standards:

• 2-CS-01: Recommend improvements to the design of computing devices, based on an analysis of how users interact with the devices.
• 3A-AP-16: Design and iteratively develop computational artifacts for practical intent, personal expression, or to address a societal issue by using events to initiate instructions.
• 3A-AP-18: Create artifacts by using procedures within a program, combinations of data and procedures, or independent but interrelated programs.
• 3A-AP-21: Evaluate and refine computational artifacts to make them more usable and accessible.
• 3A-AP-23: Document design decisions using text, graphics, presentations, and/or demonstrations in the development of complex programs.

Explore

When you hear terms like design you might think of the interior design of someone’s home, paintings in a gallery, or something related to art. Design is a much broader term, however, with applications that venture into technology and other areas.

Many programmers methodically design code and programs to make the most sense to humans. A growing field is Human Computer Interaction, where the role is to plan, strategize, and design apps and physical products for consumers or ensure a product fits a business’s needs.

Think about many of the apps you have used on your smartphone. Often, teams of developers and designers have worked together to produce a refined version of these apps which cater to what users want. This concept is called user experience, or sometimes shortened to UX design. The idea is you want the user to feel like their needs were taken into account.

Accessibility in Design

Accessible design is an important concept for designers to make sure products can be used by everyone. A major consideration that designers should follow as applicable are the Web Content Accessibility Guidelines (WCAG), which focuses on accessible design on digital products (especially websites). WCAG is unusual in that it dovetails ideas in design, like how a web page is structured, but also serves as legal guidelines from the U.S. Department of Justice as of 2024 [1]. The changes made by this rule are significant, arguably a sea change, in that they require accessibility to be the default under certain conditions. There is plenty of nuance to be considered, but here are some examples of the type of information related to WCAG:

• Alternative Text (Alt-Text) on images and diagrams.
• Requiring appropriate color contrast for readability by anyone, but especially those with low or limited vision
• Providing adequate information for screen readers and other accessibility tools, sometimes including the use of ARIA labels or app structure.
• Providing transcripts for audio resources and subtitles for video resources.

When you begin programming your own apps, one thing you can do to make your apps feel more accessible is to ensure that all of your labels and buttons have meaningful, clear, names. While partially subjective, this allows any user to understand what is happening in your programs, even if they are using accessibility tools like a screen reader.

Most programming languages support libraries for accessibility, in one form or another, but they vary considerably. Sometimes, features that may not seem accessibility related are. For example, languages must support keyboard navigation, present information to screen readers, and support some method for interacting with the operating system's accessibility layer. Further, languages can make it easier or harder to make applications accessible. With color, another common issue in accessibility, if a language makes non-WCAG compatible choices with color contrast, some or many users may find an app harder to read.

Creating an App

Most programming languages have some mechanism for creating applications or apps, but what that means varies. For Quorum, apps are coded in one language and in one way, then generated for each platform you are on. The idea is you can write an app once, then run it on desktop, on the web, or on your phone.

Sometimes, if you want your app to work everywhere, you might need subtle changes on one platform or another. When you think about it, this makes sense. If you are deploying an application on a phone, where there are gestures, this might have a very different design than with a keyboard or mouse.

The library you will be focusing on for this lesson is the Form library. The Form library lets you add buttons, input fields, banners, images, etc. and program all these features so that they work with one another. In this lesson, you will learn about the structure and some basic elements within the Form library.

Accessing the Form Library

Throughout this lesson's Parsons problems, you will be working with some common actions and objects. If you use Quorum offline, you can also generate this and other templates and obtain a wide variety of other interface choices and designs. Remember though, although there are helpers for using this offline, the code is the same. Whether you learn the code offline or online leads to the same or a similar result. Here is the an example of the type of code you will be using in the practice problems:

use Libraries.Interface.Forms.Form
use Libraries.Interface.Forms.Page
Form form
Page page = form:GetMainPage()

page:AddButton("Hi")
form:Display()

This template creates a default, puts a button labeled Hi on it, and loads it. Note you do not need to embed any additional accessibility information. The application is automatically born accessible. Visually, the following shows what this would look like:

The first two lines,

use Libraries.Interface.Forms.Form

and

use Libraries.Interface.Forms.Page

are the libraries that contain all the objects required to create the form app. The next line,

Form form

creates your form object. The Form object is a graphical display that will open a window for your app to run in. Forms are also in charge of storing and keeping track of the different pages in your app. Some users prefer to give an object a different name (e.g., not form to avoid it being the same). What you name it is your choice and personal preference. The next line reads

Page page = form:GetMainPage()

A Page is a single screen on your app, including all of the buttons, labels, and other elements that will be on that screen. Just like viewing people’s profiles on social media, the new displays are new pages. When you use

form:GetMainPage()

you are requesting that the system gives you the first Page that will be displayed when the app starts. The system also calls this the main Page. Any kind of interactive user interface component, like buttons, text boxes, fields, lists, trees, or other items, are added to a page, but not the form itself. The idea is that then your app can flip pages as you go to show different kinds of information to the user.

Now that you have a Page, you add elements directly to it. This will make your elements appear on the screen. You can see the next line is

page:AddButton("Hi")

This will add a button with a label that says Hi on the first page of the app. Screen readers and other accessibility clients will read that the button is named Hi. If you prefer, you can change the name of the item or the description, which alters what accessibility devices would obtain. Finally, in order to actually use the app, you use

form:Display()

This will make the Form open the window and display the main Page. While the template is convenient for creating a Form, it is not required. You could also choose to begin with a blank project and manually type out the libraries and the objects. While this method might be more tedious, all the information is the same. The key elements you should always include in your Form programs should be:

use Libraries.Interface.Forms.Form
use Libraries.Interface.Forms.Page 

Form form 
Page page = form:GetMainPage()

form:Display()

These five lines of code will be in most Form programs you create. All the other pieces of code are for you to explore and learn to practice creating user interfaces.

Accessibility in Design

In order to add a button to your app, you must add it using the Page object by using page:AddButton(name). The button’s label (and also the button’s name) will match the text you provide to the action.

Alternatively, if you have an image file (such as one with the extension JPG or PNG), you can make a button using that image. In this case, you can use page:AddButton(name, filename), where the filename is a path to where the image is located. The path is always relative to your project’s location on your computer, so if you use this option, it is highly recommended you store your image files in your project folder. In an online system, the Quorum website includes a small collection of sample images by default. Here is a sample of some dinosaur images:

Adding Labels

To add text labels to your app, you need to add a label to the Page by using page:AddLabel(name). The provided text will be both the label’s name as well as the text that it displays. By default, labels can be navigated by a screen reader.

Adding a Banner

A Banner is a more complex element that can include multiple parts. How many parts are present in your app depends on how much information you give the action to make it. If you provide just a single piece of information using page:AddBanner(title), the banner will have a single label with your given text.

Alternatively, if you give a second piece of text using page:AddBanner(title, label), the banner will have both a title label and a secondary label beneath it. Finally, the third option, page:AddBanner(name, title, label) works similarly to the previous option. In this case, the first value is the name, which will be read by screen readers and other accessibility technologies. Then, the second and third values are the title text and secondary label, respectively. You can use this option if you want to fine-tune the accessibility information separate from the text of the title.

Citations

1. U.S. Department of Justice. Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments. April 2024. https://www.ada.gov/resources/2024-03-08-web-rule/

Engage

So far, you have learned about user interfaces and how to set up a basic app. There are a few challenges in managing Parsons problems with forms and the big one is that user interfaces are at least partially subjective. One person can invent what seems useless to one person, but might be very important to another. Further, because the interfaces are at least partially subjective, your code here is not automatically checked.

Directions

Just like all of the practice problems, you can drag and drop, use the keyboard, or even just write in the editor the solution to the problem and run the code. As a reminder, the hotkey to run the code is ALT + SHIFT + R on Windows and CTRL + SHIFT + R on Mac.

1. Learn about Form objects

Next Tutorial

In the next tutorial, we will discuss Actions Online, which describes how to write your own actions.