Closed cfm closed 2 years ago
@eloquence, per https://github.com/freedomofpress/securedrop/issues/5972#issuecomment-947317684, here is the translation distance incurred by the draft of #6165:
cfm@ozymandias securedrop % make translate
Updating translations...
[...]
cfm@ozymandias securedrop % git diff --compact-summary securedrop/translations/messages.pot
securedrop/translations/messages.pot | 119 ++++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 85 insertions(+), 34 deletions(-)
A handful of these will be case changes that we can edit in bulk in the individual .po
catalogs before starting localization for the v2.2.0 release. The rest we'll just need to give translators adequate time to work with, especially from updated screenshots.
Thanks, that's helpful! For the string changes we can apply across language immediately, should that be done as part of #6165 already or are there good reasons to hold off on that?
On 13 Dec 2021, at 16:57, Erik Moeller wrote:
Thanks, that's helpful! For the string changes we can apply across language immediately, should that be done as part of #6165 already or are there good reasons to hold off on that?
Yep, I’ve noted this in #5987 as part of the final linting to be applied to #6165 before final review and merge. (I’ll test these manual translation updates in the Weblate sandbox, too.)
As outlined above, #6165 will be ready for review tonight pending CI. Of note, but out of scope of the current accessibility effort: The Journalist Interface’s style sheets tend to be more logical and DRYer than the Source Interface’s, but there’s still room for more consistency. For example:
a
or a button
element.[classname^="icon-"]
and then adding icon-specific background
properties: e.g., .icon-foo
→ background-image: url(foo.png)
.More broadly, with the completion of this second accessibility refactoring, I see an opportunity to use a UI framework, if one exists that can be bundled acceptably or rendered server-side, to translate the current UI into reusable components, much as we’re doing in Qt for the SecureDrop Client. Such a further refactoring would make the UI more maintainable going forward, including by taking the current template-level accessibility improvements and baking them in at the component level.
Description
Accessibility Lab recommendations include:
h1
...hn
hierarchyOur findings include:
img
elements to CSS styles on semantic elementsUser Research Evidence
WCAG 1.3.1 per #5972.
Progress
To invert the way things are usually done :-):
journalist.js
in syncimg
/hr
/etc. elements: comment out asFIXME
s to move to CSS styles on semantic elementsh1
...hn
hierarchyFIXME
ssecuredrop/journalist_templates
├──_confirmation_modal.html
├──_source_row.html
├──_sources_confirmation_final_modal.html
├──_sources_confirmation_modal.html
├──account_edit_hotp_secret.html
├──account_new_two_factor.html
├──admin.html
├──admin_add_user.html
├──admin_edit_hotp_secret.html
├──admin_new_user_two_factor.html
├──base.html
├──col.html
├──config.html
├──delete.html
├──edit_account.html
├──error.html
├──flashed.html
├──index.html
├──js-strings.html
├──locales.html
├──login.html
└──preferences_saved_flash.html
Specific cases
*modal.html
asdialog
s à la Source Interface's.{confirm,hidden}-prompt
add_user.html
h1
should not be.visually-hidden
col.html
table
securedrop/journalist_templates/col.html
:p.breadcrumbs
is a set of unstructured inline elements; could beul
styled withli:{before,after}
selectorsdiv dialog
s are still being read (unlike those inindex.html
)index.html
table
td.filename
should wrap more elegantly (or not at all)