10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

Unless otherwise stated, copyright © 2024 The Open University, all rights reserved.
Printable page generated Monday, 28 Oct 2024, 19:01

Block 1 Part 2: Foundations of the web

Mark Hall

1 Introduction
The web has firmly established itself as the primary pathway for connecting businesses, consumers, and
government. While there has recently been renewed talk of moving from the primarily text-based web to
an immersive virtual reality (VR) interface, this transition has been talked about for a long time and is
unlikely to impact the primacy of the web in the short and mid-term future.

This is in part because the technologies for VR are still somewhat clunky and expensive, and suffer from
issues such as inducing motion sickness in a significant fraction of users. However, it is mostly because
the wide range of existing services that are available via the web represent such a significant
investment, that any quick change away from this is unlikely.

The web nowadays provides a vast array of shopping, financial, social networking, entertainment, and
government services. Additionally, in the past few years web technologies have found their way into a
wide array of physical devices, allowing us to control our doorbell, heating, lights, entertainment systems
and many other devices via the web.

This wide uptake is in part due to the low barrier to entry that web technologies provide. None of the
basic software technologies for building web-related products (HTML, CSS, JavaScript, PHP, Python,
Ruby, …) require significant financial outlay to start working with them. Tutorials and learning materials
are widely available. Hardware and server resources can be rented at short notice and very low cost. All
of this makes it easy to take a business idea and make it available as a service via the web.

In Block 1 of the module we will look at these technologies that underpin the modern web. You will view
these through the lens of business requirements and how these influence what is most appropriate
when.

2 Aims
After studying this part, you will have an understanding of:

the respective roles of markup, styling, and scripting

the role and development of web standards

the practical and legal aspects of accessibility

how to use HTML, CSS, and TypeScript.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 1/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

3 Marking up structural information

Whether we are creating a static page with information to be shown to the user or a full-blown web
application, in all cases we will have data that we need to show to the user and that needs to be
structured in order to achieve our goal. While we could build something bespoke to structure the data, in
general, from a business perspective we will want to make use of existing tools and technologies. This
allows us to focus on delivering the problem solution, rather than on building tools.

The most appropriate solution in this scenario is to use a markup language to structure the information.
They are called markup languages, because the data are ‘marked up’ using structural information .
There are many markup languages in use, which can be categorised using a range of dimensions
including ease of automatic processing, readability, or range of concepts that can be represented.
Depending on our use-case, we will want to use different markup languages for different scenarios and
may even use multiple markup languages together, converting from one to the other, where necessary.

Now to look at one of our case studies and how you would use markup languages in practice. For the
music streaming business, Sounds Good!, users will want to browse the music available to them and
one aspect of that is that you need to represent the content of a music album. As the information will
mostly be entered into the system by users with less technical knowledge, a markup language that is
easier to write and read by humans is most appropriate (Hogan and Coron, 2020). Markdown is one
such markup language and below you can see an example of how you might mark up the content of an
album overview:

# The Doors
*The Doors* first album was released on January 4th 1967 on [Elektra Records](/labels/elektra-record
## Track List
1. Break on Through (To the Other Side)
2. Soul Kitchen
3. The Crystal Ship

As you can see, Markdown is relatively readable. With the exception of the syntax for including an image
() and the syntax for links ([Elektra Records]
(/labels/elektra-records)), most of the markup is relatively self explanatory. Additionally,
Markdown doesn’t really allow us to say anything about how the content is presented. This is important,
because as you will see later in this part, separating structural markup from presentation improves the
maintainability of the solution.

At the same time, because you are going to be deploying the music streaming service via the web, you
need to take technical requirements and limitations of the web medium into account. The primary
limitation is that the web browser, which is how users will access the service, only supports content
marked up using HTML (Hypertext markup language). Luckily, you can automatically convert Markdown
into the equivalent HTML:

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 2/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

<h1>The Doors</h1>
<img src="album-art-thumbnail.png" alt=""/>
<p><em>The Doors</em> first album was released on January 4th 1967 on <a href="/labels/elektra-recor
<h2>Track List</h2>
<ol>
<li>Break on Through (To the Other Side)</li>
<li>Soul Kitchen</li>
<li>The Crystal Ship</li>
</ol>

You now have your content marked up using a user-friendly markup language, but then automatically
converted for presentation in HTML via the browser. Due to the HTML limitation of the browser, this is a
pattern that you will see again and again. The markup language used for marking up the data will vary
and will frequently use some kind of custom structuring in a database, but the basic principle is the
same.

Throughout this module you will focus mostly on using and generating HTML directly, so next you will
consider HTML, how it administered and how it is structured.

3.1 Web Hypertext Application Technology Working Group

The HTML markup language is a relatively old markup language. The first version became available in
1993 and the first formal specification was released in 1995. From version 3.2, released in 1997, the
HTML standard was developed and standardised by the World Wide Web Consortium (W3C), who you
will look at in more detail when you look at styling. After the release of HTML 4.01 development of the
HTML standard slowed down, as the W3C focused on an XML-based replacement called XHTML.

During the early 2000s the use of the web increased significantly, with new browsers (Google Chrome,
Opera, Firefox, Safari) joining the, by then monopoly, of Microsoft’s Internet Explorer 6. This resurgence
in browser development reignited the desire to further develop the HTML standard, which coalesced
under the banner of the Web Hypertext Application Technology Working Group (WHATWG) in 2004,
which in turn released the first version of HTML 5 in 2008.

Disagreement developed between the WHATWG and the W3C’s HTML working group about the
process of developing HTML 5. The WHATWG, which was (and is) dominated by browser producers,
wanted a more continuous development process, using a ‘Living Standard’, while the W3C wanted to
keep the more formal release process that had been used in the past. As a result throughout the 2010s
there were essentially two parallel version streams of the HTML 5 standard. The ‘HTML Living Standard’
developed by the WHATWG, which due to it being developed by the browser manufacturers, was the
de-facto standard developers referred to, and the ‘HTML 5.0, 5.1, and 5.2 standards’ as formally release
by the W3C. In 2019 the W3C formally ceded authority over the HTML standard to the WHATWG,
codifying what had already happened in reality. The HTML 5.0, 5.1, and 5.2 standards have since been
deprecated and are no longer official in any way.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 3/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

The authoritative reference for HTML is thus now the HTML Living Standard, however in practice the
documentation available at the Mozilla Developers Network (MDN) is more useful, because it combines
in one place documentation for not only HTML, but also CSS, JavaScript, and the various Web APIs.
Throughout this block you will cover a range of these technologies, but will not be able to investigate all
of them. You are thus encouraged to spend a bit of time familiarising yourself with the MDN site, so that
you know where to look in the future.

Activity 1 Markup with HTML

40–60 minutes

With these foundations in place, it is now time to try out the practicalities of marking up content
with HTML. Go to the Block 1 activities and there undertake the Week 2 Markup with HTML
activity. When you have completed the activity, return here.

4 Styling markup
Markup on its own is very useful and for users using accessibility support tools, is often the only thing
that matters. However, you should also make sure that the marked-up content is visually appealing.

The important thing in this respect is that you always ensure that your markup is as separate as possible
from the styling. The reason for this is that the content generally evolves at a different speed to the
styling. In particular the styling is frequently updated at a much more rapid rate than the content,
whether this is to take advantage of new features offered by the browser, make the content more usable
based on user feedback, or to take into account re-branding work. In none of these cases do we want to
have to make significant changes to the markup, just to accommodate changes in the styling.
Sometimes, obviously, this will be necessary, but it is best try to avoid it as much as possible.

4.1 World Wide Web Consortium

For the web and for HTML, the language used for styling content in this module is CSS (Cascading Style
Sheets). The CSS specification is still maintained by the World Wide Web Consortium (W3C), although
nowadays the standard is split into many separate modules.

The first version of CSS was released in 1996, followed quite quickly by the second version in 1998.
One of the things that became apparent in the work on the next version was that some aspects of the
CSS standard could be worked on and improved quite easily, while in other areas there was significant
disagreement on how features should work.

As a result of this need to move at different speeds, there was a CSS 2.1 release in 2011, but even
before that, for CSS 3, the decision was made that the standard would be split into multiple ‘modules’.
Each module could then be evolved at the speed appropriate for the area. Thus, while the W3C
publishes annual ‘Snapshots’ of the CSS standard, there is no (and there will be no) CSS 3 release.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 4/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

Because the ‘Snapshots’ are primarily targeted at browser implementers and include those parts of the
different modules that are sufficiently stable to be implemented, they are of less interest to the web
developer, who is more interested in what is supported by browsers. The two most useful sources for
that are the MDN and Can I use, both of which provide information on which CSS features are
implemented in which browsers to which degree.

Activity 2 Styling with CSS

40–60 minutes

With these foundations in place, it is now time to try out the practicalities of styling HTML pages
with CSS. Go to the Block 1 activities and there undertake the Week 2 Styling with CSS activity.
When you have completed the activity, return here.

5 Scripting and dynamic pages

The combination of HTML and CSS enables the distribution of visually styled content via the web, but
users on the modern web expect more than just static information display, they expect interactivity and
in the browser this is implemented using JavaScript.

The JavaScript language was originally added to early browsers as a simple scripting language to
enable basic interactivity and dynamic pages. Over time the language has developed into a fully-
featured programming language that is standardised as ECMAScript. This standardised version of
JavaScript is a pure programming language. The JavaScript you interact with when coding for the web
takes this pure programming language and extends it with the APIs provided by the browser, to create
the complete JavaScript experience.

The result of this split also means that while JavaScript is the only programming language understood
by browsers, it is also possible to run JavaScript outside of the browser and in particular it has found a
space as a server-side programming language as well (see Node.JS). The advantage being that a
complete product can be built in a single programming language.

Fundamentally JavaScript is a high-level, interpreted, dynamically typed, object-oriented programming

language. High-level means that it abstracts a lot of the complexity of dealing with processes and
memory. As an interpreted language, the JavaScript engine directly executes the source code that is
provided to it, rather than requiring a compiler to turn source code into executable code. Both of these
things have performance implications, however modern JavaScript Engines use just-in-time (JIT)
compilation to optimise the code. The architectures of these engines are highly specialised to achieve
the level of performance seen in modern browsers, but fundamentally use a range of heuristics and to
optimise the code and speed up its execution.

JavaScript is a dynamically typed language, which means that the type of a variable is defined by the
type of its value. This means that the type of a variable can change whenever a value is assigned to that
variable. However, in practice and to make it harder to introduce bugs it is recommended that each

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 5/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

variable is only assigned values of the same type. This also has the advantage that the JIT compiler can
further optimise the code.

5.1 TypeScript
As mentioned earlier, JavaScript is a dynamically typed language, where the type of a variable can
change during its execution. Thus in JavaScript, we could write the following code:

let x = 0;
x = x + 2;
x = x + 'px';

It defines the variable x with the value 0. Then it adds 2 and assigns the result back to x. Finally, it adds
the string 'px' to the value of x and assigns the result back to x. After the first two lines of code the
variable x contains a value of type number, while after the third line, the type of the value of x is a string.
This is perfectly valid in JavaScript, because in JavaScript the type is attached to the value, not the
variable. Thus a variable can, and will, change its type.

While at first glance this is very practical, because it cuts down on the amount of typing to do, it opens
the door to a number of problems. The biggest is that because the type of a variable is defined by its
value, when values are passed to functions or APIs, it is up to the developer alone to check that the
value has the correct type at all times. The difficulty with this is that it is often hard to track exactly what
the current type of a variable is, thus it is easy to have a mismatch between the actual and expected
variable type, which can lead to bugs. The lack of explicit typing also means that any such typing errors
can only be discovered at runtime, turning the relatively straightforward task of type checking into a
complex debugging activity. For the same reason the editor is also unable to provide any meaningful
kind of support during editing.

TypeScript is an extension to JavaScript that, among other things, adds a full type system to JavaScript.
Now look at the following code sample that adds type information to the earlier JavaScript code:

let x : number = 0;
x = x + 2;
x = x + 'px'; // The TypeScript compiler will complain here

As you can see, the only change in the code is the addition of : number in the first line. However, this
has two immediate effects. First, your editor can use the type information to highlight that in the third line
you are assigning a string to a number. Second, the TypeScript compiler will also be able to detect this
and will raise an error. Both of these steps can be automated, allowing the developer to focus on
implementing functionality.

The main limitation of TypeScript is that the browser cannot directly execute it. Instead, it is necessary to
compile any TypeScript code into JavaScript. However, as you will see in the exercises, when using
modern web development frameworks, these generally come with this kind of conversion already set up,
thus there is only limited extra complexity for the developer.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 6/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

Activity 3 TypeScript

40–60 minutes

With this context in place it is now time to undertake a series of activities on using TypeScript. Go
to the Block 1 activities and there undertake the Week 2 TypeScript activity. Remember, that
because the VCE stores your progress, you can interrupt the activities at any time and continue at
a later point. When you have completed the activities, return here.

6 Accessibility
Up to this point the user has not been considered, except in so far as to make the markup match the
semantics of the content and the styling visually usable and attractive. There is, however, one aspect of
the user that you are legally required to take into consideration and that is what adjustments have to
made to ensure that the website or webapplication is accessible to all users.

When the topic of accessibility comes up, there is sometimes a perception that making a site accessible
means making it accessible to blind users. That is part of it, but there is a long list of factors that can
impact on accessibility and the true aim of accessible is ‘Design for all’, meaning that all users with all
and any additional needs can access the information you have designed.

The following list gives an overview over the different kinds of issues users can face, and which have to
be taken into account to ensure full accessibility:

loss of vision
colour blindness
hearing loss

dyslexia
dyscalculia
dyspraxia

mobility impairments
epilepsy
attention deficit-hyperactivity disorder

reduced cognitive function.

This list is illustrative of the spectrum of accessibility needs users can have, but in no way an exhaustive
list of all the issues users could face. Often it is also the case that users have multiple accessibility
needs and it is the combination of these needs that creates the complexity in developing a fully
accessible solution (Georgakas, 2023).

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 7/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

6.1 Legal aspects

Accessibility is closely related to usability and user experience, in that a site that has accessibility issues
effectively has usability and user experience issues. However, while the aim is always to provide users
with a usable interface and a pleasant user experience, accessibility differs in one specific way and that
is that it is a legal requirement.

In the UK accessibility is fundamentally covered under the Equality Act 2010 and the Disability
Discrimination Act 1995 in Northern Ireland. In particular the legislation requires all ‘service providers’ to
make ‘reasonable adjustments’ to ensure that all users, regardless of their accessibility needs can
access the services they provide. It is not fully specified what a ‘service provider’ is, but clarification
issued by the UK Equality and Human Rights Commission stated that all web sites constitute a ‘service’
as they provide access to physical or digital goods and services, as well as provide information. This
fundamentally means that the ‘service provider’ is anybody who runs a website.

There are exceptions to this requirement, where complying with the regulations might be a
‘disproportionate burden’. However, to use the exception, an organisation would have to undertake an
accessibility audit to weigh up the cost burden of making things accessible and the benefits that would
provide to users with accessibility needs. While initially the technology needed for accessibility on the
web was rudimentary, nowadays this has evolved to such a degree that the number of areas where the
adjustments may be a ‘disproportionate’ burden have significantly shrunk, to a point where they barely
exist.

In the context of our case studies, if we consider a user who is significantly partially sighted, or has
complete blindness, then neither of the case studies could make a case that supporting such a user
would be a disproportionate burden. However, if we were to consider a user with a significant learning
difficulty, who requires support for preparing any kind of object for shipment, then the ‘Mercury’ shipping
company could make a case that they do not need to make adjustments to support such a user as a
sender, because the complexity would be significant and such a user would never use the system on
their own. At the same time, they could not make the same case for the process of receiving a shipment,
as that could well be within the user’s abilities. Similarly, the ‘Sounds Good!’ music streaming service
would have to support the use of their service by such a user, at least in parts. While such a user may
not necessarily be expected to select a playlist themselves, they can expect to be able to start and stop
the playback and navigate around the tracks. As such ‘Sounds Good!’ is required to make the necessary
adjustments to support that.

The second important aspect is what is a ‘reasonable adjustment’. The Equality Act defines these as
adjustments as:

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 8/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

take reasonable steps to ensure equal experience and avoid the disadvantage for persons
with disabilities in their practice,

take reasonable steps to avoid the disadvantage for persons with disabilities against persons
who are not disabled by fixing physical features that could cause such,

take reasonable steps to provide an auxiliary aid if, without it, persons with disabilities would
be at a disadvantage in comparison with persons who are not disabled.

Equality Act, 2010

This provides more detail, but there is still the question of what exactly, at a technical level, needs to be
adjusted. Technical standards of this type are, in the UK, often formulated by the British Standards
Institution (BSI) and they have developed BS 8878 (Web Accessibility), which states that an organisation
should:

Design accessible and usable websites for all internet users

Designate clear responsibility with a written web accessibility policy and a member of staff
responsible for its administration

Keep accessibility in mind – organisations should emphasise accessibility in all stages of web
design

Review sites – seek feedback from website users and test sites to ensure that they stay
accessible as technology develops

BSI 8878, 2010

While BS 8878 does not directly provide technical specifications for accessibility, it is strongly linked to
the International Standards Organisation’s standard ISO/IEC 40500 ‘W3C Web Content Accessibility
Guidelines (WCAG) 2.0’. As you will see later, the WCAG guidelines provide specific guidance and can
be used as the basis for testing and ensuring a website is accessible. We will go into the details later,
but in practice the WCAG guidelines are what you should use and currently stand at version 2.2.

Some final limitations that need to be overcome for legal compliance are what are known in WCAG as
the conformance levels. WCAG provides three, ranging from lowest (A) to highest (AAA). Obviously the
amount of work required to reach a certain level increase with the level. There is no concrete guidance
for non-public-sector websites and apps, however the Public Sector Bodies (Websites and Mobile
Applications) (No. 2) Accessibility Regulations, which came into force in 2018, states that public-sector
websites and apps must be compliant with WCAG 2.1, conformance level AA. Using that as a guideline
is most likely a sensible baseline from which to start pushing accessibility improvements and likely
ensuring legal compliance.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 9/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

6.2 Business aspects

In the previous section you looked at the legal requirement for accessibility. Legal drivers for
accessibility are important, but of much more importance are the business drivers. The reason for this
higher importance is that the legal drivers essentially place accessibility as a cost of conducting a legal
business. However, accessibility is not only a cost, but an important income driver.

While, still, frequently marginalised, people living with a disability make up a significant fraction of the
population, with around 11% of children, 23% of the working-age population, and 45% of the pension-
age population having some kind of disability (Department for Work and Pensions, 2023). All of them will
benefit from improved accessibility.

Looking at the business case for accessibility, this means that in the UK there are around 1.14 million
children, 8.9 million working-age adults, and 4.9 million pension-age adults, who need at least some
accessibility support in order to access the services a business provides. If you combine this with the
amount of spending power available to families with at least one disabled person in the household,
which is estimated at £274 billion per year, then we are looking at a significant revenue stream that is
being held back by a lack of accessibility.

The business case is strengthened even further by the fact that people living with a disability are more
likely to make use of online resources. The reason for this is that interactions with the physical world
often present additional hurdles that can be difficult to overcome. Without accessibility the same hurdles
exist in the digital world, but implementing accessibility consideration, and thus lowering the digital
barriers, is often much easier than providing the same level of improvement in the physical world.

Now that the business driver is in place and the legal aspects in mind, you can turn to look at the
technology specifications for assessing and implementing accessibility.

6.3 Web Content Accessibility Guidelines

You already met the W3C earlier as the original HTML and CSS standards organisation. In addition to
these core aspects, the W3C undertakes standardisation work in a range of other domains, including
accessibility, where the primary standard is the Web Content Accessibility Guidelines. The WCAG
defines four aspects under which accessibility is achieved:

Perceivable: information and user interface components must be presentable to users in ways
they can perceive. This covers aspects such as providing text-based alternatives for video/audio
content, but also colour choices, colour contrast, font sizes, and related properties.

Operable: user interface components and navigation must be operable. The primary aspect here
is that a user interface must be operable and navigable via the keyboard only, but also that users
are given enough time to interact with the system, that the interaction patterns do not trigger any
kind of seizures or physical reactions.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 10/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

Understandable: information and the operation of user interface must be understandable. This
means that the language used should be appropriate for the target audience, but also that the
interaction patterns can be predicted by the user and that the user is provided with understandable
support to avoid and correct any mistakes.

Robust: content must be robust enough that it can be interpreted by a wide variety of user agents,
including assistive technologies.

In addition the WCAG provides the three levels of conformance:

A: the most basic level of conformance. Conformance with this level will alleviate the worst
accessibility issues, but accessibility hurdles will remain for many users.

AA: the ‘standard’ level of conformance. As mentioned earlier, this is the level that is generally
seen as achieving legal compliance level and will ensure that the majority of users with
accessibility needs can fully use the website.

AAA: the highest level of conformance. Conformance with this level will ensure that only a very
small sub-set of accessibility needs will not be satisfied.

The WCAG provides a number of success criteria for achieving accessibility, with each criterion aligning
with one of the three conformance levels and providing details of what is required to achieve
conformance. Now look at the following example of the Contrast (Minimum) criterion:

Success Criterion 1.4.3 Contrast (Minimum)

(Level AA)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for
the following:

Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least
3:1;
Incidental: Text or images of text that are part of an inactive user interface component, that
are pure decoration, that are not visible to anyone, or that are part of a picture that contains
significant other visual content, have no contrast requirement.

Logotypes: Text that is part of a logo or brand name has no contrast requirement.

The criterion has a title and a unique number, below that the conformance level and then a description of
what conformance implies. In this case, for colour contrast between the foreground and background
colour, the contrast ratio has to be 4.5:1, except in the listed exceptions.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 11/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

In addition to giving the developer support in designing the interface and interaction patterns, the criteria
can also be evaluated automatically and there are a number of tools available for doing this, including:

WAVE
axe

Chrome Developer Tools

Firefox Developer Tools

When you are developing a website of any kind, it is good practice to regularly run your site against
these tools, to ensure that it is sufficiently accessible.

6.4 Accessible Rich Internet Applications

The WCAG criteria aid with designing for accessibility and then testing the result. However, they do not
provide tools for extending websites with accessibility markup beyond those provide with the HTML
standard. This gap is filled by the Accessible Rich Internet Applications (ARIA) suite of web standards.
This is particularly necessary for modern websites that make heavy use of dynamic and interactive
features, which without additional markup, cannot be supported by existing assistive technologies.

ARIA provides web developers with the following main elements:

Roles to describe the type of widget an HTML element provides.

Roles to describe the structure of a web page

Properties to describe the state of widgets.

Properties to define live regions of the page.

A definition for how keyboard navigation for these aspects should be implemented.

Roles
The core ARIA principle is the role attribute, which is an attribute that you can specify on an HTML
element, just like any other attribute:

<div role="dialog">
<div>Task Notification</div>
<p>This is a notification example.</p>
</div>

In this example there is a <div> element, with the role attribute set to "dialog". This informs the
browser and any assistive technologies, that the element and its content represent a dialog window. A
screenreader could use this to read out the text ‘Dialog window. Task notification. This is a notification
example.’ By being able to include the first ‘Dialog window’ part based on the role attribute, the user
using the screenreader gets a better idea of the role that the content plays, without the web developer
having to explicitly include that text.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 12/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

ARIA provides a range of roles that exceeds what we can present here, but the available roles fall into
five categories (there is a sixth category, but that is only for organisation purposes and must not be used
directly):

1. Widget roles: are used to identify user interface widgets and includes specific roles such as
buttons, menus, menu items or grids.

2. Document structure roles: describe roles used to structure the content in the page and cover
aspects such as articles, tables, lists or headings.

3. Landmark roles: are similar to document structure roles, but represent navigational landmarks
within the page that are often used by assistive technologies to provide fast navigation through the
page. These include roles such as the banner, form, main, navigation or search.

4. Live region roles: indicate to the assistive technology that the content is an area that is frequently
updated, including roles such as alert, log, status and timer.

5. Window roles: represent elements that are acting as windows within the browser, such as dialogs.

What is important with these roles is that many HTML elements are implicitly granted matching roles.
For example using the <button> element, automatically assigns the button role to that element.
Similarly, using the <main> element gives that element the main role. Where there is an element that
has a specific role as its implicit role, you should always use that element, rather than using a different
element, such as a <div>, and assigning the role explicitly.
Properties
ARIA specifies a large number of additional properties, all of which start with aria-, that are used to
specify additional information about the content and state of an element that has an ARIA role (whether
explicit or implicit).

Some of these properties provide relatively static information, such as the aria-label attribute which
can be used to provide a text-representation of an element that otherwise has none. For example in the
following example

<button aria-label="Close the dialog">

<img src="..." aria-hidden="true"/>
</button>

aria-label is used to provide a text label for a <button> that only contains an image. This way a
screenreader can simply read out ‘Button close the dialog’. Additionally, we specify aria-
hidden="true" to also tell the screenreader that it can ignore the <img> element. While the assistive
technology can also ignore these attributes, they are useful in providing the assistive technology user
with a smoother user experience.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 13/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

In addition to these more static attributes, there are also attributes such as aria-checked or aria-
selected which can be used to indicate that a given element has been checked or selected. The value
of these attributes is likely to change as the user interacts with the web page.
Authoring practices guide
Due to the large amount of roles and properties and their interactions, ARIA also comes with an
Authoring practices guide. This complements the main specification by providing a large number of
implementation patterns, but also other guides and best practices for using the ARIA technologies
appropriately.

One thing that is of importance with the use of ARIA technologies is that these should only be used
where necessary and that using them comes with additional implementation requirements. For example,
a website frequently has a horizontal list of sections at the top of the page, often with dropdown sub-
sections attached to them. It may seem like these are a perfect candidate for the menubar ARIA role and
if correctly implemented, then that may be the case. However, setting the menubar also requires that,
depending on the state of the menubar, specific additional aria-* attributes are set, as well as
implementation of the keyboard navigation as specified in the specification document . If implemented
completely and correctly and if the number of elements is sufficiently large, then this will give a better
user experience. However, it also sets up expectations, such as being able to navigate through the
menubar with the arrow keys, and if those are not met, then the user experience will be worse than if the
user simply had to use the tab key to navigate through all the items.

One of the developments that we are seeing recently is that user-interface frameworks for the web are
starting to come with the necessary ARIA functionality included. This reduces the amount of work for the
individual developer and you should take advantage of this wherever it is available.

Activity 4 Accessible Rich Internet Applications

40–60 minutes

Implementing accessible interactive interfaces is generally simple if one follows basic guidelines,
but there are edge cases where it can be quite complex. Go to the Block 1 activities and there
undertake the Week 2 Accessible Rich Internet Applications activity. When you have completed the
activity, return here.

7 Summary
You have now completed the Part 2 of Block 1 and have had a refresher of the basics of producing an
accessible, dynamic website. The remainder of the block will build upon this foundation,using web
services and more complex front ends using a range of frameworks.

Where next?

You are now ready to move on to Block 1 Part 3, where you will look at the basic architectures that

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 14/15
10/28/24, 7:00 PM Block 1 Part 2: Foundations of the web: View as single page | OU online

underpin the modern web.

References
British Standards Institution (BSI) (2010) Website accessibility for all: a consumer’s guide to the British
Standard for Web Accessibility (BS 8878). Available at: https://www.bsigroup.com/LocalFiles/en-
GB/consumer-guides/resources/BSI-Consumer-Brochure-Web-Accessibility-UK-EN.pdf (Accessed 13
July 2023).

Equality Act 2010 c.15. Available at: https://www.legislation.gov.uk/ukpga/2010/15/contents (Accessed

13 July 2023).

Department for Work and Pensions (2023). Family resources survey: financial year 2021 to 2022.
Available at: https://www.gov.uk/government/statistics/family-resources-survey-financial-year-2021-to-
2022 (Accessed 12 June 2024).

Georgakas, D. (2023) A11Y Unraveled: become a web accessibility ninja. Berkeley, CA: Apress.
Available at: https://doi.org/10.1007/978-1-4842-9085-9

Hogan, B.P. and Coron, T. (2020) Build websites with Hugo: fast web development with markdown.
Raleigh, NC: Pragmatic Bookshelf.

https://learn2.open.ac.uk/mod/oucontent/view.php?id=2353272&printable=1 15/15