Reading system is the generic term used in EPUB to describe the application used to read or process a publication.

A reading system can be a dedicated device like an eInk tablet, or could be an application like Kobo Books, Google Play Books and Apple iBooks, that runs in a tablet, phone or on a computer.

In EPUB 3, a remote resource is a resource that is hosted on the Web instead of being included inside the ZIP container file.

Audio, video and fonts are examples of resources that are allowed to be located on the web. The reason this is allowed is to speed up the download time of the publication, so users can begin reading faster.

Render is a presentation-neutral term used to describe how a reading system makes a publication readable for a user.

For visual reading, for example, rendering entails the visual lay out and styling of the content on a screen. For auditory reading, rendering involves playing back pre-recorded audio or generating text-to-speech playback.

In EPUB 3, a rendition of a publication is one presentation of its content.

All publications consist of one default presentation, but it is technically possible for more than one presentation to be bundled together. For example, a digital publication could have separate English and French versions, or a fixed layout and reflowable version for readers to choose from.

In practice, however, renditions are more theoretical than practical at this time. A means of selecting between possible renditions was developed for EPUB 3, but has never gained any traction either with publishers or reading system developers.

A rendition is not the same things as its possible renderings. Each rendition could be rendered multiple ways (e.g., visually, aurally, tactilely)

Resource is a generic term used to refer to anything used in the rendering of a digital publication. Resources include the files in a container or anything that can be obtained from the web.

Although it might be simpler to think of resources as "files", the word file is generally avoided because publication resources may not exist until they are retrieved (e.g., a script might dynamically generate a resource to return to a reading system).

The three major components of the ARIA specification are the definition of roles, states and properties for making interactive content accessible.

Roles identify the purpose that an element serves so that assistive technologies understand how to make the content usable. For example, the role button could be assigned to a span element to indicate that is has been scripted to function like a clickable button. An assistive technology can then make that element clickable by the user even though it normally wouldn't be.

States are used to keep track of changes to an element as users interact with it. For example, if an element has been assigned the role checkbox, assistive technologies need to know if the checkbox is in a checked or unchecked state. States are managed by scripts as they change.

Properties represent attributes of an element. They are similar to states, but typicaly less likely to change. A button can be assigned a name using either the aria-label or aria-labelledby attributes, for example. Similarly, a slider might set its minimum and maximum value properties using the aria-valuemin and aria-valuemax properties.

Taken together, roles, states and properties allow developers to emulate built-in HTML elements (like button and input) and also make many common scripting patterns more easily usable for users of assistive technologies.