JS Modules
- We can split JS functionalities across modules
- You can then
import modules as necessary
- Allows better code management
A module is a separate JS
file
- Other modules then can use features from a given module
Making features
available to other modules
in dayname.js
const names = ["Sunday", "Monday", "Tuesday"]
export function dayName(number) {
return names[number];
}
export function dayNumber(name) {
return names.indexOf(name);
}
export in front of features will make them available to
other modules
You can use a single
export statement
const draw = () => {};
const reportArea = 16.5;
export { draw, reportArea };
a single export statement at the end of the module with
a comma-separated list of the features
Importing features from a
module
in main.js
import {dayName} from "./dayname.js";
The dot (.) in "./dayname.js" indicates
current folder
You can also rename
imported features
import { name as squareNameOne } from "shapes";
You can import all features
as well
import * as Module from "./modules/module.js";
Module.function1();
Module.function2();
Applying the module to your
HTML
index.html
<script type="module" src="main.js"></script>
Must include type="module"
Todo
- Open Activity
21 in VS Code
- Two modules
- Try to access the names variable from
dayname.js in main.js
- e.g., print using
console.log
- What happens?
Todo
- Rewrite
dayname.js to use a single export
statement
names should also be exported
Todo
- Rewrite
main.js to use import * as ...
syntax
Todo
- Open Activity
22 in VS Code
- Check Dev Tools –> Console
- Can you fix the errors?
Hints
- Export features
canvas.js
square.js
draw, reportArea,
reportPerimeter, randomSquare
Hints
- Import those features in
main.js from
canvas.js and square.js
Accessibility
Commonly abbreviated as a11y
Accessibility
- Nearly 20% of
individuals in the US have some form of disability
- 1 billion people around the world
Users
might have specific requirements and constraints
- Visual impairment
- Hearing impairment
- Physical impairment
- Speech impairment
- Seizures
- Cognitive and learning disabilities
Accessibility
As a designer and developer, it is our
responsibility to provide ways for these users to engage
with our system
Better
accessibility results in improved usability for everyone
Better
accessibility === Improved usability for all
Closed captioning and
transcripts
- Initially designed for deaf users
- Almost every college student has used
captioning and transcripts
Better
accessibility === Improved usability for all
Curb cuts
- Initially for wheelchair users
- Improves experience for all (pedestrians, cyclists, …)
Better
accessibility === Improved usability for all
Electric toothbrush
- Initially designed for
- Patients with limited motor skills
- Orthodontic patients (e.g., with braces)
We all can benefit
from better accessibility
- Temporarily disabled
- Situationally disabled
- Unable to play audio in public for a video message
Accessibility
is about enabling all of your users
- Failing to make your product accessible means potentially excluding
a significant number of users
Accessibility
might be legally required for some products
- Requirement for public sector entities
- Government funded programs, nonprofits, …
- Might be required for some private sector companies
Accessibility
might be legally required for some products
“In the US, Over ten lawsuits are filed daily focused on digital
accessibility”
Accessibility
- Principles
- Guidelines
- Tools
Accessibility principles
Perceivable,
Operable, Understandable, and Robust (POUR)
![]()
Perceivable
- All essential information must be perceivable to
all users
- For different types of disabilities (e.g., visual, mobility, …)
- Examples
- Text alternatives to essential icons and images
- Captions
- Not relying on only color to convey meaning
Operable
- Users must be able to operate the interface
- Can’t require interaction that a user is unable to perform
Operable by all users
- Examples
- Keyboard and touchscreen support to all active elements
- Giving users enough time to fill out a form
Understandable
- Information and the interface operation must be understandable
- Examples
- Has predictable navigation
- Error messages are clear and easy to resolve
Robust
- Accessible to users using both older and future technologies
- Examples
- Works for different screen reader technologies
- Content and functions work for different device sizes
Accessibility
- Principles
- Guidelines
- Tools
Semantic html leads
to better accessibility
<div>Play video</div>
👎🏾 Don’t
<button>Play video</button>
👍🏾 Do
Use the correct HTML elements
Structure page sections
logically
<header>
<nav>
<main>
<article>
<aside>
<footer>
- …
Structure page sections
logically
<header>
<h1>Header</h1>
</header>
<nav>
<!-- main navigation in here -->
</nav>
<!-- Here is our page's main content -->
<main>
<!-- It contains an article -->
<article>
<h2>Article heading</h2>
</article>
<aside>
<!-- aside content in here -->
</aside>
</main>
<footer>
<!-- footer content in here -->
</footer>
Use semantic UI
controls whenever possible
- Use buttons, links, and form controls
- Provides default keyboard accessibility
Use semantic UI
controls whenever possible
<!-- Using <div> for buttons -->
<div data-message="First button">Click me!</div>
<div data-message="Second button">Click me too!</div>
👎🏾 Don’t. Use buttons instead
Use meaningful text labels
- Button and link text labels should be understandable and
distinctive
- Try to avoid using “Click here”
- Context might be lost for screen reader users
Make sure your
labels make sense out of context
Try to avoid using “Click
here”
Whales are really awesome creatures.
To find out more about whales,
<a href="whales.html">click here</a>.
👎🏾 Don’t
Whales are really awesome creatures.
<a href="whales.html">Find out more about whales</a>.
👍🏾 Do
Use Form
label to provide context
Fill in your name: <input type="text" id="name" name="name" />
👎🏾 Don’t
<label for="name">Fill in your name:</label>
<input type="text" id="name" name="name" />
👍🏾 Do
Text alternatives
- Images can’t be seen by people with visual impairment
- We should provide
alt description for the screen
reader
Provide
alt description for non-decorative images
<img src="old-main.png" />
👎🏾 Don’t
<img
src="old-main.png"
alt="The Penn State Old Main building"/>
👍🏾 Do
Provide
alt description for non-decorative images
- Describe the image and what it conveys visually
- Should be brief and concise
- Do not duplicate the surrounding text
Empty alt is
ok for decorative images
<img src="article-icon.png" alt="" />
When the image is only for visual decoration
Color
Click the green button for next item
👎🏾 Don’t
Color contrast
- The foreground and background color contrast is important
- Make sure that people with color blindness can read the content
Accessibility
- Principles
- Guidelines
- Tools
Have
you started thinking about the final project topic?