serrebi/Accessible-IPTV-Client

Watch

Fork 0

mirror of https://github.com/serrebidev/Accessible-IPTV-Client.git synced 2026-08-13 07:49:09 -07:00

Optional feature suggestions for an improved accessible IPTV #4

New issue

Open

opened 2026-06-22 09:04:29 -07:00 by serrebi · 0 comments

serrebi commented

2026-06-22 09:04:29 -07:00

Owner

Hi!

Thank you again for your continued work on Accessible IPTV Client and for being so open to feedback.

I have collected several ideas that could further improve the application, particularly for blind, visually impaired and keyboard-only users. These are optional feature suggestions rather than bug reports or urgent requests. I fully understand that their feasibility and priority depend on the future direction of the project.

Favourites

It would be useful to:

add or remove channels from a dedicated Favourites group;
preserve favourites when playlists are refreshed or replaced;
provide an accessible keyboard command for toggling the favourite status of the selected channel.
2. Recently watched channels and previous-channel command

Possible additions could include:

maintaining a list of recently watched channels;
providing a command to return immediately to the previously viewed channel;
optionally allowing a dedicated key, such as 0, to switch between the current and previous channels.
3. Direct channel-number entry

The application could allow users to type a channel number and switch directly to the corresponding channel.

An optional screen-reader-friendly confirmation could announce or display, for example:

Channel 123, BBC News.

Audio-track selection

It would be helpful to provide access to all available audio tracks, including:

original and dubbed audio;
audio-description tracks;
language information;
a keyboard command for cycling through the available tracks.
5. Subtitle management

Possible subtitle-related options could include:

turning subtitles on or off;
selecting the subtitle language;
loading an external subtitle file;
exposing subtitle text through accessibility APIs or providing optional subtitle speech, if technically feasible.
6. “What is playing?” command

A single keyboard command could announce or display:

the channel name;
the current programme;
its start and end time;
the next programme;
the current recording status.

This could allow a screen-reader user to obtain the most important playback information without moving focus away from the current control.

Configurable accessibility announcements

Users could choose how much automatic spoken or accessible feedback the application provides.

Possible levels could include:

no automatic announcements;
errors only;
important events;
detailed status information.

Useful announcements might include channel changes, buffering, reconnection attempts, recording start and completion, and playback errors.

Customisable keyboard shortcuts

Users could be allowed to redefine commands for:

playback;
channel switching;
volume;
EPG;
recording;
casting;
audio-track selection;
subtitle management.

The application could warn the user if a chosen shortcut conflicts with an existing command.

Recurring and series recording

Building on the existing DVR scheduler, possible future additions could include:

daily or weekly recurring recordings;
recording every programme with a matching title;
warnings about overlapping or conflicting recordings;
configurable time margins before and after a programme.
10. Secure settings export and import

The application could provide a way to export and restore:

playlists;
EPG settings;
favourites;
interface preferences;
keyboard settings.

Provider credentials could be excluded by default. Alternatively, they could be included only in a password-encrypted backup.

Accessible diagnostic report

A diagnostic-report function could collect information such as:

the application version;
the operating-system version;
the active screen reader;
VLC and FFmpeg status;
the most recent error;
relevant non-sensitive configuration details.

Passwords, access tokens, complete provider URLs and other sensitive information should be masked automatically.

The report could then be copied to the clipboard or saved as a text file for inclusion in a bug report.

Searchable keyboard and accessibility help

A native, keyboard-accessible Help window could provide:

a complete list of keyboard shortcuts;
screen-reader usage notes;
information about focus behaviour;
instructions for using EPG, recording, casting and provider configuration;
searchable and copyable text.

These suggestions are intended only as possible long-term improvements. I am not expecting all of them to be implemented, and I understand that some may be difficult or impractical within the current architecture.

I hope some of these ideas may be useful when considering the future development of the application. I would be very happy to help test any accessibility-related additions with JAWS and NVDA and to review any related Hungarian interface strings.

Thank you very much for considering these suggestions and for continuing to develop an IPTV application with keyboard and screen-reader accessibility in mind.

Best regards,

Tibor Hermann

Hi! Thank you again for your continued work on Accessible IPTV Client and for being so open to feedback. I have collected several ideas that could further improve the application, particularly for blind, visually impaired and keyboard-only users. These are optional feature suggestions rather than bug reports or urgent requests. I fully understand that their feasibility and priority depend on the future direction of the project. 1. Favourites It would be useful to: add or remove channels from a dedicated Favourites group; preserve favourites when playlists are refreshed or replaced; provide an accessible keyboard command for toggling the favourite status of the selected channel. 2. Recently watched channels and previous-channel command Possible additions could include: maintaining a list of recently watched channels; providing a command to return immediately to the previously viewed channel; optionally allowing a dedicated key, such as 0, to switch between the current and previous channels. 3. Direct channel-number entry The application could allow users to type a channel number and switch directly to the corresponding channel. An optional screen-reader-friendly confirmation could announce or display, for example: Channel 123, BBC News. 4. Audio-track selection It would be helpful to provide access to all available audio tracks, including: original and dubbed audio; audio-description tracks; language information; a keyboard command for cycling through the available tracks. 5. Subtitle management Possible subtitle-related options could include: turning subtitles on or off; selecting the subtitle language; loading an external subtitle file; exposing subtitle text through accessibility APIs or providing optional subtitle speech, if technically feasible. 6. “What is playing?” command A single keyboard command could announce or display: the channel name; the current programme; its start and end time; the next programme; the current recording status. This could allow a screen-reader user to obtain the most important playback information without moving focus away from the current control. 7. Configurable accessibility announcements Users could choose how much automatic spoken or accessible feedback the application provides. Possible levels could include: no automatic announcements; errors only; important events; detailed status information. Useful announcements might include channel changes, buffering, reconnection attempts, recording start and completion, and playback errors. 8. Customisable keyboard shortcuts Users could be allowed to redefine commands for: playback; channel switching; volume; EPG; recording; casting; audio-track selection; subtitle management. The application could warn the user if a chosen shortcut conflicts with an existing command. 9. Recurring and series recording Building on the existing DVR scheduler, possible future additions could include: daily or weekly recurring recordings; recording every programme with a matching title; warnings about overlapping or conflicting recordings; configurable time margins before and after a programme. 10. Secure settings export and import The application could provide a way to export and restore: playlists; EPG settings; favourites; interface preferences; keyboard settings. Provider credentials could be excluded by default. Alternatively, they could be included only in a password-encrypted backup. 11. Accessible diagnostic report A diagnostic-report function could collect information such as: the application version; the operating-system version; the active screen reader; VLC and FFmpeg status; the most recent error; relevant non-sensitive configuration details. Passwords, access tokens, complete provider URLs and other sensitive information should be masked automatically. The report could then be copied to the clipboard or saved as a text file for inclusion in a bug report. 12. Searchable keyboard and accessibility help A native, keyboard-accessible Help window could provide: a complete list of keyboard shortcuts; screen-reader usage notes; information about focus behaviour; instructions for using EPG, recording, casting and provider configuration; searchable and copyable text. These suggestions are intended only as possible long-term improvements. I am not expecting all of them to be implemented, and I understand that some may be difficult or impractical within the current architecture. I hope some of these ideas may be useful when considering the future development of the application. I would be very happy to help test any accessibility-related additions with JAWS and NVDA and to review any related Hungarian interface strings. Thank you very much for considering these suggestions and for continuing to develop an IPTV application with keyboard and screen-reader accessibility in mind. Best regards, Tibor Hermann