Incomplete requirements for EAA: accessibility info in EPG for AVMS

An interesting proposed requirement that might be a good addition. I wonder whether the phrase "presenting media item(s)" is clear. If a media item is defined as you suggest, which seems reasonable, then "presenting" could be understood as playing! Would it not be more appropriate to use a term such as "listing"? List might tend to be understood as a text-based list, but the actual items listed, would probably be a still image with a title under it (or similar). Perhaps the understanding of what is meant by "listing" could be explained, with examples, in a note.

Given that the proposed requirement uses the term electronic programme guide (EPG) in its pre-condition, I think that it is essential that this term is included in the list of terms. This definition would need to also include the term "media item" in some way to clearly link the two meanings.

I suspect it would be difficult to fit all that information into the typical "grid" representation of programming that spans multiple channels and a broad time period, even if each was reduced to a single icon. I agree it would be helpful if it appeared on the main description of the programme when highlighted, but even there space is very limited as you can see from this picture.

(Apologies for the glare/reflection. This was taken moments ago from my Swisscom IPTV set-top box EPG, but it's pretty much universal.)

Also, remember that EPGs often have to be clearly readable from across a room, including by people with limited vision. Crowding more information onto the screen can actually have a negative impact for some viewers.

@jeffreym, both of your comments are true, but there is an explicit EAA requirement that such information should be available and specifically identifies EPGs.

Any creative suggestions on how to specify an alternative requirement that is both implementable, usable, and that meets the EAA requirement?

Well, the EPG is more than just the grid. It also refers to the more details pages that can be seen when a content item is selected. To be truly precise, the EPG is actually the data that is sent to the device, not the way it is presented on screen, but of course even the EAA gets this confused.

So my approach would be to require the information be displayed

When it is made available in the EPG data, and
In those views of the EPG data where it can be accommodated without adverse impact on the viewing experience

We could also recommend that the presence of such information is displayed in other views, so that users know they can get more details.

We could also recommend that the user interface provides some means to highlight or filter what is listed based on specific accessibility features.

Sorry, I'm triple-booked today so not able to give this much thinking time right now.

On further reflection, the originally proposed requirement uses the term:

"; such identification shall be at the same navigation level as the listing of media items"

The phrase "at the same navigation level" and similar have proved to be very controversial with TV product suppliers and is no less so here.

My initial interpretation of this is that the information should be shown in each of the program cells in the matrix. Small icons representing captions, etc. do appear in some EPGs in these per-program cells (I think). More common is to have such icons in the box at the top of the screen that gives a summary of the program, small icons are quite common and feasible. But are these "at the same navigation level as the listing of media items", the answer is not a clearl "yes" or "no" on this to me.

Is there any agreed or standard iconography around accessibility features? Maybe that should be a separate work item.

The phrase "; such identification shall be at the same navigation level as the listing of media items" is not something that is required in EAA Annex I(IV)(b)(i). The usefulness of the "information about the availability of accessibility" would be maximised if this additional condition is met, but it is not explicitly required by the EAA, and as @jeffreym points out, attempting to meet it could actually cause negative effects like making the EPG less legible when viewed at a typical viewing distance.

A possible way to resolve these issues is to use the following requirement and note:

Where ICT is or includes an electronic programme guide (EPG) presenting media item(s), and the media item(s) have captions, audio description, spoken subtitles, or sign langauge interpretation,
the ICT shall provide information that identifies which media items in the EPG have captions, audio description, spoken subtitles, or sign language interpretation.

NOTE: The information about the which accessibility features are available is needed when a user is assessing which programs will be accessible to them. They will need this information to be visible when they are viewing or scrolling through the EPG.

I thought about extending the note, but then it gets more into the fine details of UI design. The "or scrolling through" caters for the most common situation in EPGs that provide this information, where the information is only visible for the program that is described by the cell where the screen selection pointer lies.

It will always be possible to increase the size of the cells in the EPG so that the accessibility information could be placed in every cell, but this can only be done at the expense of having fewer cells in view at any one time. It is probably best left to designers to choose how they design their EPG to optimise the tradeoffs between those who would like lots of programs in a single view versus the many who would benefit from immediately visible information on the accessibility features of every program in their EPG.

added EAA Alignment label

I agree with the direction of this thread. On the one hand, I could easily imagine an in-app user preference that would add icons to EPGs like the example photo. On the other hand, I can imagine other EPGs with still less space, and I agree it's challenging to define a "navigation level" concept.

Could the requirement say something like "without activating each programme" to find the accessibility information? Such a requirement could be met with persistent identifiers in the EPG (as discussed in this thread), or with identifiers that appear only as a result of an in-app preference, or a faceted search, or a filtered view of the programs based on the desired accessibility feature.

Note that the main text of EAA Annex I also requires to "ensure interoperability with assistive technologies. Thus also a requirement on the EPG in Annex I (IV)(b)(i)

Again, the actual EPG is the data that is sent to the ICT by the service provider. I worked for a few years in a small standards body (TV Anytime) that created the ETSI standards (the TS 102 822 series) for EPG data (a very rich structure of XML) that is sometimes but not always used for this.

How the EPG data is presented to the user is the job of the ICT, and the EN is supposed to set the requirements for that. But I wish we could be consistent in that the EPG itself is the underlying data, over which the ICT has no control, only over how it is presented on screen.

What the EPG data contains, including what accessibility indicators are present, is out of scope for our EN. So we shouldn't be phrasing requirements as "what the EPG must do", but as "how the ICT needs to present EPG data to the user".

But yes, the EAA itself sometimes gets this distinction confused. We should not be adding to that confusion.

Taking onboard the above information, such as @jeffreym's point that the EPG is data and the ICT can only display data that is included in the EPG, and @mtchllvn's point about multiple methods of providing this information and the need to ensure that finding out what accessibility features are available "without activation", could lead to the following formulation:

Where ICT is or includes an electronic programme guide (EPG) presenting media item(s), and the EPG includes information about the availability of captions, audio description, spoken subtitles, or sign language interpretation for the media item(s),
the ICT shall provide a mode of operation in which the availability of captions, audio description, spoken subtitles, or sign language interpretation can be determined without activating each program.

NOTE: The information about the which accessibility features are available is needed when users are assessing which programs will be accessible to them. They will need this information to be available to them when they are viewing or scrolling through the EPG.

I don't think "Where ICT is or includes" makes much sense.

Could we say "Where ICT includes the presentation of electronic programme guide (EPG) data describing media item(s) ..."

Do you think it is possible to avoid that this new requirement focuses only on EPGs, while still addressing EAA Annex I(IV)(b)(i)?

Adding a requirement focusing only on one particular type of service does not seem to fit with the philosophy that has been followed so far in the EN. Especially when other services similar to EPGs (offering access to listings of multimedia items) but that are not EPGs will not be addressed by this new clause in its current form, or by any other clauses in the EN, according to the last modifications to Chapter 12, see issue #541 (closed).

EN301549 (and all international standards on ICT accessibility) require that multimedia shall have accessibility components, however the current status is far from ideal, for example in educational institutions.

Hence, having information on the accessibility of multimedia items will inform end users' search and use of documents in any multimedia repository, not only in digital TVs.

Gunnar is pointing out that the new clause also needs to support the text of the requirement at the very beginning of Section IV: "[..] ensure interoperability with assistive technologies"

Hence I am proposing below a new wording for the requirement, partially based on what was discussed in issue #503 (closed).

Where ICT is or includes listings of multimedia items that allow users to browse and select content, it shall provide information on the availability of captions, audio descriptions, spoken subtitles, or sign language interpretation for each media item, as well as on its compatibility features with assistive technology.

NOTE 1: An electronic programme guide (EPG) is an example of ICT addressed in the present clause.

NOTE 2: Compatibility features include accessibility features and AT that are built-in and accessibility features that provide compatibility with 3rd party assistive technology.

NOTE 3: It is best practice to not only offer this information directly to users but also to use standardized vocabularies to provide metadata on the accessibility of the ICT, such as "Schema.org Accessibility Properties for Discoverability Vocabulary" [i.40], or "Service and discovery metadata - DVB" [i.X].

NOTE 4: It is best practice to present information on the accessibility in a manner that is understandable to users. There exists guidance in this respect, such as the "User Experience Guide for Displaying Accessibility Metadata 1.0" [i.Y].

I’m sorry, I think this proposal goes much too far beyond what is required by the EAA, which really is specific to actual EPGs.

EPGs are specific to linear content (broadcast or streamed), to tell the user what is coming up (or recently happened) on the schedule of each linear channel and something about it so that they can decide to watch, or to set it for recording.

Alejandro’s proposal would create a requirement applicable to any catalog of multimedia content, for example, on-demand programming or even just media files that happen to sit in a file folder. Those are not EPGs, so that goes far beyond the EAA requirement.

Also, the part of the proposal about “compatibility features with assistive technology” makes no sense to me. This is not a requirement for the AVMS content itself (which is not in-scope for either the EAA or the EN) but rather for the AVMS access service (which is in-scope for EAA).

I cannot find a definition for Electronic Programme Guide (EPG) in the EAA.

Historically, of course, EPG:s have been mostly about linear content. But I would have expected the EAA requirements for EPG:s to be applicable to a wider range of program guides that are popular today, including

the listing of TV content offered by, for example the website https://player.bbc.com, where the user can select between linear "live" content and on-demand content that is offered for streaming, usually for a few weeks.
apps from TV stations that offer functionality similar to the above
apps or websites from VOD providers such as Netflix and Disney+

But I would not have expected the EPG term to cover file systems as soon as they contain multimedia content.

So the wording proposed by @rodriguezasc :

"listings of multimedia items that allow users to browse, select and play content, and its main purpose is to distribute multimedia content"

fits quite well with my expectations. But I am not in any way an expert in this specific topic, so I would hope to find a definition in the EAA.

However, I do find a definition in section 310(8) of the UK Communications Act 2003:

"a service which consists of — (a) the listing or promotion, or both the listing and the promotion, of some or all of the programmes included in any one or more programme services the providers of which are or include persons other than the provider of the guide; and (b) a facility for obtaining access, in whole or in part, to the programme service or services listed or promoted in the guide."

As far as I can tell, this also matches @rodriguezasc proposal.

Please understand that "programme service" in television (or radio) is defined as "a concatenated series of broadcast events", what most of us would think of as a "channel". Don't get it confused with the (very many) other uses of the word "service".

The EPG is the data transmitted by the broadcast service for linear channels. This is a defined term in ETSI, and has multiple standards (and probably regulations) associated with it. For example:

https://www.etsi.org/deliver/etsi_en/300700_300799/300707/01.02.01_60/en_300707v010201p.pdf

The EAA didn't need to define it, because it's a well understood term.

I do not believe we are allowed to reinterpret the terminology in the EAA to mean something different from normal industry usage.

The implications of going beyond the EAA could be quite severe on other kinds of services, and would probably result in organisations having to abandon conformance to the EN while still adhering to the EAA itself, and having to explain that divergence.

For example, imagine a simple web page that has conventional hyperlinks to a variety of media files. For example, a local choir with a page of video recordings from their latest concerts, or a service that carries training videos for a specific industry audience. This overbroad interpretation of what the EAA really requires would sweep up thousands of such cases. Heck, I'm using an app to learn British Sign Language and even that would come into violation of this extended requirement.

Please stick to what the EAA actually requires.

(I spent eight years developing television standards including the TV-Anytime project that developed the ETSI standards for EPG metadata. I'm also still a member of the SMPTE.)

Responding to @pluke's 2025-03-19 proposal #485 (comment 20082)

@rodriguezasc wrote:

Do you think it is possible to avoid that this new requirement focuses only on EPGs, while still addressing EAA Annex I(IV)(b)(i)? ... having information on the accessibility of multimedia items will inform end users' search and use of documents in any multimedia repository, not only in digital TVs.

I agree that users have much the same need to find accessible media in video-on-demand (VOD) catalogues, which the EAA and the 2025-03-19 proposal do not address.

On the one hand, other requirements could mostly meet user needs in some cases, like this ideal scenario:

In a listing of training videos, all the videos meet 9.1.2 (and 7.1.5 where applicable).
The website accessibility statement mentions that videos have captions, audio description, and spoken subtitles where needed.
In this scenario there is no need for the listing to highlight which videos are accessible, because they all are.

("Mostly met" — if some of the videos have sign language, then there is a user need to find those.)

On the other hand, because of regulatory exemptions for older videos and leniency for on-demand AVMS, user needs to find accessible videos will continue indefinitely.

@jeffreym wrote:

Alejandro’s proposal would create a requirement applicable to any catalog of multimedia content, for example, on-demand programming or even just media files that happen to sit in a file folder. Those are not EPGs, so that goes far beyond the EAA requirement.

M/587 allows EN standards to go beyond EAA. Where they do go beyond, "the structure of a harmonised standard shall be such that a clear distinction can be made between its clauses and sub-clauses that are necessary for compliance with the accessibility requirements of Directive 2019/882 and those that are not" in Annex Z.

Is it possible to split this proposal into two clauses, one clause narrowly addressing EPGs and another clause addressing all media listings?

If not, then I don't see how we can do much better than the 2025-03-19 proposal.

In my view, EAA acknowledges the users’ need to have information about the accessibility of contents available in a multimedia repository. The fact that it only addresses EPGs may obey to social and legal aspects, not related to the technical ones a standard on user requirements like EN301549 shall consider.

Like @mtchllvn says, in a perfect world all videos (e.g. in a learning institution) would comply with 9.1.2. However, that is not the reality. In a previous post to this thread I shared a paper describing what the situation is in top-ranked universities as for multimedia accessibility. Imagine how it goes in other institutions with less resources. The case for sign language is even worse, since its availability is not covered by 9.1.2. The case of accessible contents in VOD platforms is not very different. These are good reasons for supporting discoverability of audiovisual resources that are accessible to people with disabilities.

I agree with @jeffreym that limiting the categories of repositories addressed by the clause is not easy. Maybe the wording

“Where ICT is or includes listings of multimedia items that allow users to browse , select and play content, and its main purpose is to distribute multimedia content”.

would exclude unaddressed, generic file services.

As for the proposal’s part on “compatibility features with assistive technology”, the full requisite in Annex I Section IV reads:

"The provision of services in order to maximise their foreseeable use by persons with disabilities, shall be achieved by including functions, practices, policies and procedures and alterations in the operation of the service targeted to address the needs of persons with disabilities and ensure interoperability with assistive technologies:

(b) Services providing access to audiovisual media services:

(i) providing electronic programme guides (EPGs) which are perceivable, operable, understandable and robust and provide information about the availability of accessibility;"

So, I think @jeffreym is right in saying that the requirement focuses not on the content but on the service. In the EN words, an EPG shall not be produced as a closed functionality ICT. And that is not properly stated in the text I proposed.

What about?

Where ICT is or includes listings of multimedia items that allow users to browse , select and play content, and its main purpose is to distribute multimedia content

it shall provide information on the availability of captions, audio descriptions, spoken subtitles, or sign language interpretation for each media item, and it will support interoperability with assistive technology.

NOTE 1: An electronic programme guide (EPG) is an example of ICT addressed in the present clause.

NOTE 2: Compatibility features include accessibility features and AT that are built-in and accessibility features that provide compatibility with 3rd party assistive technology.

NOTE 3: It is best practice to not only offer this information directly to users but also to use standardized vocabularies to provide metadata on the accessibility of the ICT, such as "Schema.org Accessibility Properties for Discoverability Vocabulary" [i.40], or "Service and discovery metadata - DVB" [i.X].

NOTE 4: It is best practice to present information on the accessibility in a manner that is understandable to users. There exists guidance in this respect, such as the "User Experience Guide for Displaying Accessibility Metadata 1.0" [i.Y].

We are ONLY supposed to be doing updates to meet the EAA requirements.

The EAA only talks about actual EPGs for this requirement, probably for good reason. I therefore do not believe we are allowed to expand the requirements into other catalogues of multimedia items at this time.

If anything, we could have a "should" recommendation for other media list types, but we do not have the authority to mandate it.

Incomplete requirements for EAA: accessibility info in EPG for AVMS

EAA

Currently in EN 301 549

Proposed

Other global standards

Designs

Child items ...

Activity