This site uses cookies. By continuing to browse the site, you agree to our use of cookies. Find out more about it here.
#BeaMember - A new form of commitment to Decidim
Decidim

Last activity

Type
Results per page:
  • 12/03/2020 19:21
  • New proposal at Propose new functionalities for Decidim software
    Allow admins to see a participant's email from their profile page
    This feature is building on this one: https://github.com/decidim/decidim/issues/5722 In the following PR (https://github.com/decidim/decidim/pull/5849), the possibility for an admin to see a participant's e-mail has been added to the participants list in the admin panel. I am suggesting to add the exact same button to the profile page of the user, next to the currently existing button to send a private message (see screenshot). This button would trigger the exact same behaviour (popup with a button to "show" the address and would of course log the action in the same way. The reasoning behind this suggestion is that the admin using our platforms often work from the content (proposals, initiatives...) and then might need to contact its author (for clarifications, etc...). When they do so, it is better to give them access to the e-mail in a context-based way rather than forcing them to copy the user's name, going to the admin panel, searching for the right user (potentially mistakenly picking the wrong one) and pressing the button. Finally, I would add that this is C
  • 11/03/2020 23:20
  • New proposal at Report a Bug
    [WCAG 2.1 / AA: 3.2.2] Do not dynamically change the page content on filtering f...
    The WCAG 2.1 says that individual form inputs should not change the context of a web page. Only the submit button of a form should change the context as that is what users would be accustomed to on web pages. Another way is to advise the user in advance what the form does but I believe this would add unnecessary complexity to the view. In case the dynamic fields are kept, they should be marked with an aria-controls attribute indicating only the changed part. E.g. on the proposals page we cannot target the element with ID "proposals" with this as it has the sorting controls before the changed context starts. The implementation should be rethought if the dynamic filtering needs to be kept. Here's also one additional view about the aria-controls attribute: https://heydonworks.com/article/aria-controls-is-poop/ Currently the sidebar filtering forms e.g. on the proposals page do not meet the WCAG criteria on this.
  • 11/03/2020 16:15
  • New proposal at Propose new functionalities for Decidim software
    Link assemblies to PP page
    Hello everyone, Our client wants to access linked assemblies on PP presentation pages, as we currently can access a PP by clicking on its card on linked assemblies presentation page. As a user I want to be able to access to a linked assembly when navigating on a PP page. As an admin, when linking a PP to an assembly on the assembly config page, I want the link to go both ways. Now, the link is just visible on the Assemblies presentation page, but not on PP page. See mockup below
  • 10/03/2020 22:31
  • New proposal at Report a Bug
    [Accessibility] Get rid of ALLCAPS headings and buttons in the default Decidim s...
    ALLCAPS headings/buttons are bad for accessibility: - They make the text less readable - They are problematic for dyslexic people - Some screen readers read them letter by letter, even if the capitalization has been made using CSS This kind of styling is not particularly forbidden by the WCAG 2.1 guidelines but makes the system less accessible e.g. for the mentioned reasons, so it should not be encouraged by Decidim's default styling. Further reading: https://github.com/humanmade/hm-pattern-library/issues/75 https://accessibility.huit.harvard.edu/design-readability Also, why are ALLCAPS forbidden in the proposal titles by the etiquette validator if they are enforced in Decidim's own headings? ;)
  • 10/03/2020 22:06
  • New proposal at Report a Bug
    [WCAG 2.1 / AA: 3.2.3, 3.2.4] Accessibility violations on button and link stylin...
    One important Decidim’s accessibility criteria violation concerns the navigational and functional link and button styling. In the attached screenshot I've gathered visually similar buttons into their own groups found on Metadecidim. The main problem is that we have at least 11 groups of different styles of buttons for a single application. According the the accessability experts, we should have the following styles for buttons: - Primary (e.g. Group A) - Secondary (e.g. Group G) Makes the UI clearer and more understandable as the user gets accustomed to the two simple styles of buttons. Other one can be one can be functional, e.g. publish a proposal (primary) and the other navigational switching from one view to another (secondary). Regarding the links, the accessibility experts suggest that: - All links should have the same styling - Links should not appear in grey color unless they are disabled
Creative Commons License Website made with free software.

Please sign in

Forgot your password?

Or