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

Accessibility, keyboard navigation and localization issues found in the current source code #3

New issue

Open

opened 2026-06-19 14:49:03 -07:00 by serrebi · 0 comments

serrebi commented

2026-06-19 14:49:03 -07:00

Owner

Hi Serrebi,

First of all, I would like to thank you sincerely for developing Accessible IPTV Client and for taking accessibility and localization seriously.

As a blind Windows user who works with both JAWS and NVDA, and as the person currently reviewing the Hungarian translation, I greatly appreciate the amount of work that has already gone into making the application usable from the keyboard and with screen readers.

I would like to share several observations regarding the current source code. My intention is not to criticise your work, question your decisions, or tell you how the application should be developed. I am sending these notes only as a constructive accessibility and localization report, in the hope that they may help improve the application further.

I have tried to separate the points carefully into three categories:

issues that still appear to be present in the current source code;
items that may require runtime verification with JAWS and NVDA;
optional privacy, security and usability improvements.

Some of the observations below are based on static source-code review. Therefore, where the actual screen-reader behaviour has not yet been reproduced, I have deliberately described the item as something that may need testing rather than as a confirmed runtime defect.

Items that appear to be present in the current source code
1.1 Explicit accessible names in the main window

Several important controls in the main window appear to be created without explicit accessible names or associated visible labels.

These seem to include:

the channel-group list;
the channel-filter field;
the channel list;
the EPG information field;
the stream URL field.

Depending on how wxPython exposes these controls to Windows accessibility APIs, JAWS and NVDA may announce only generic control types such as “list box”, “edit field” or “read-only edit field”.

It may be helpful to assign clear accessible names, for example:

Channel groups
Filter channels
Channels
Current and next programme
Stream URL

I am not claiming that all of these controls are necessarily announced incorrectly in every environment, but explicit accessible names would make their purpose unambiguous and reduce reliance on memorising the Tab order.

1.2 Accessible names in the Playlist Manager and EPG Manager

The primary list controls in the Playlist Manager and EPG Manager also appear not to have explicit accessible names.

Possible names could include:

Configured playlists and providers
Configured EPG sources

The provider configuration dialogs already contain careful accessibility labelling, so the project appears to have an existing implementation pattern that could also be applied to these list controls.

1.3 Tab and Shift+Tab behaviour in the “What’s on Now” window

The programme list in the “What’s on Now” window appears to intercept the Tab key and move focus directly to the search field.

The relevant behaviour seems equivalent to:

if the pressed key is Tab:
move focus to the search field;
stop further key processing.

The handler does not appear to distinguish between Tab and Shift+Tab.

This may result in the following keyboard-navigation problems:

Tab and Shift+Tab may both move to the same control;
the normal forward and backward dialog focus order may be interrupted;
it may be difficult to move naturally from the programme list to the Play, Schedule Recording and Close buttons;
users may experience a focus loop or an unexpected focus path.

It may be safer to preserve the standard dialog Tab order, or to handle Tab and Shift+Tab separately while ensuring that every control remains reachable in both directions.

1.4 Unicode and accented characters in type-ahead search

The type-ahead search handler in the programme list appears to accept only key codes in the range from 33 to 126.

This is essentially the basic ASCII range and does not include many non-English characters.

For Hungarian users, this may exclude letters such as:

á
é
í
ó
ö
ő
ú
ü
ű

As a result, typing the first letter while focused on the programme list may not work correctly for programme names beginning with an accented character.

A Unicode-aware method, such as GetUnicodeKey() or an equivalent character-based check, may provide more reliable behaviour in localized interfaces.

This issue may also affect other languages that use non-ASCII characters.

1.5 The currently airing programme is indicated visually

In the detailed channel EPG window, the currently airing programme appears to be distinguished primarily by bold font formatting.

This is useful visually, but a screen reader may not announce the font-weight difference automatically. Consequently, a blind user may not know which programme is currently on air.

It may be helpful to provide the same information in a textual or accessibility-compatible form, for example:

add “Now” or “Currently airing” to the item text;
provide a dedicated Status column;
include the state in the accessible name of the row;
automatically select the currently airing programme rather than always selecting the first item.

The important point is that information conveyed visually should also be available non-visually.

1.6 User-facing EPG strings that appear to bypass gettext

Several user-facing EPG strings still appear to be written directly in English rather than passed through the gettext translation function.

Examples appear to include text similar to:

Loading EPG for this channel…
EPG import in progress
Show:
Channel:
Start:
End:
Now:
Starts at
No program currently airing.
Next:
No EPG data for this channel.
Note: EPG import in progress

If these strings are not wrapped in the translation function, they may remain in English even when Hungarian or another interface language is selected. They may also be omitted when the POT translation template is regenerated.

This point is particularly relevant while the Hungarian PO file is being reviewed, because even a complete translation catalogue cannot translate strings that are not exposed to gettext.
I hope these observations are useful.

I would like to emphasise that I am sharing this report as constructive accessibility and localization feedback. My intention is not to criticise the project or to insist on any particular implementation, but to help identify issues that may otherwise be difficult to notice during development.

I greatly appreciate that Accessible IPTV Client is being developed with keyboard and screen-reader users in mind.

I would be very happy to assist with:

testing the relevant controls with JAWS and NVDA;
checking Tab and Shift+Tab navigation;
testing Unicode and Hungarian accented characters;
verifying how the currently airing programme is presented to screen-reader users;
reviewing additional translatable strings;
checking the Hungarian terminology and translations.

Thank you very much for your time, your openness to feedback, and your continued work on the application.

With Best regards,

Tibor Hermann

Hi Serrebi, First of all, I would like to thank you sincerely for developing Accessible IPTV Client and for taking accessibility and localization seriously. As a blind Windows user who works with both JAWS and NVDA, and as the person currently reviewing the Hungarian translation, I greatly appreciate the amount of work that has already gone into making the application usable from the keyboard and with screen readers. I would like to share several observations regarding the current source code. My intention is not to criticise your work, question your decisions, or tell you how the application should be developed. I am sending these notes only as a constructive accessibility and localization report, in the hope that they may help improve the application further. I have tried to separate the points carefully into three categories: issues that still appear to be present in the current source code; items that may require runtime verification with JAWS and NVDA; optional privacy, security and usability improvements. Some of the observations below are based on static source-code review. Therefore, where the actual screen-reader behaviour has not yet been reproduced, I have deliberately described the item as something that may need testing rather than as a confirmed runtime defect. 1. Items that appear to be present in the current source code 1.1 Explicit accessible names in the main window Several important controls in the main window appear to be created without explicit accessible names or associated visible labels. These seem to include: the channel-group list; the channel-filter field; the channel list; the EPG information field; the stream URL field. Depending on how wxPython exposes these controls to Windows accessibility APIs, JAWS and NVDA may announce only generic control types such as “list box”, “edit field” or “read-only edit field”. It may be helpful to assign clear accessible names, for example: Channel groups Filter channels Channels Current and next programme Stream URL I am not claiming that all of these controls are necessarily announced incorrectly in every environment, but explicit accessible names would make their purpose unambiguous and reduce reliance on memorising the Tab order. 1.2 Accessible names in the Playlist Manager and EPG Manager The primary list controls in the Playlist Manager and EPG Manager also appear not to have explicit accessible names. Possible names could include: Configured playlists and providers Configured EPG sources The provider configuration dialogs already contain careful accessibility labelling, so the project appears to have an existing implementation pattern that could also be applied to these list controls. 1.3 Tab and Shift+Tab behaviour in the “What’s on Now” window The programme list in the “What’s on Now” window appears to intercept the Tab key and move focus directly to the search field. The relevant behaviour seems equivalent to: if the pressed key is Tab: move focus to the search field; stop further key processing. The handler does not appear to distinguish between Tab and Shift+Tab. This may result in the following keyboard-navigation problems: Tab and Shift+Tab may both move to the same control; the normal forward and backward dialog focus order may be interrupted; it may be difficult to move naturally from the programme list to the Play, Schedule Recording and Close buttons; users may experience a focus loop or an unexpected focus path. It may be safer to preserve the standard dialog Tab order, or to handle Tab and Shift+Tab separately while ensuring that every control remains reachable in both directions. 1.4 Unicode and accented characters in type-ahead search The type-ahead search handler in the programme list appears to accept only key codes in the range from 33 to 126. This is essentially the basic ASCII range and does not include many non-English characters. For Hungarian users, this may exclude letters such as: á é í ó ö ő ú ü ű As a result, typing the first letter while focused on the programme list may not work correctly for programme names beginning with an accented character. A Unicode-aware method, such as GetUnicodeKey() or an equivalent character-based check, may provide more reliable behaviour in localized interfaces. This issue may also affect other languages that use non-ASCII characters. 1.5 The currently airing programme is indicated visually In the detailed channel EPG window, the currently airing programme appears to be distinguished primarily by bold font formatting. This is useful visually, but a screen reader may not announce the font-weight difference automatically. Consequently, a blind user may not know which programme is currently on air. It may be helpful to provide the same information in a textual or accessibility-compatible form, for example: add “Now” or “Currently airing” to the item text; provide a dedicated Status column; include the state in the accessible name of the row; automatically select the currently airing programme rather than always selecting the first item. The important point is that information conveyed visually should also be available non-visually. 1.6 User-facing EPG strings that appear to bypass gettext Several user-facing EPG strings still appear to be written directly in English rather than passed through the gettext translation function. Examples appear to include text similar to: Loading EPG for this channel… EPG import in progress Show: Channel: Start: End: Now: Starts at No program currently airing. Next: No EPG data for this channel. Note: EPG import in progress If these strings are not wrapped in the translation function, they may remain in English even when Hungarian or another interface language is selected. They may also be omitted when the POT translation template is regenerated. This point is particularly relevant while the Hungarian PO file is being reviewed, because even a complete translation catalogue cannot translate strings that are not exposed to gettext. I hope these observations are useful. I would like to emphasise that I am sharing this report as constructive accessibility and localization feedback. My intention is not to criticise the project or to insist on any particular implementation, but to help identify issues that may otherwise be difficult to notice during development. I greatly appreciate that Accessible IPTV Client is being developed with keyboard and screen-reader users in mind. I would be very happy to assist with: testing the relevant controls with JAWS and NVDA; checking Tab and Shift+Tab navigation; testing Unicode and Hungarian accented characters; verifying how the currently airing programme is presented to screen-reader users; reviewing additional translatable strings; checking the Hungarian terminology and translations. Thank you very much for your time, your openness to feedback, and your continued work on the application. With Best regards, Tibor Hermann