Skip to content

Commit 23f8a89

Browse files
Dhruvi16Dhruvi16
committed
merge master branch
2 parents f05c592 + 4e7dfbf commit 23f8a89

File tree

20 files changed

+675
-20
lines changed

20 files changed

+675
-20
lines changed

‎content/blog/authors/dhruvkb/contents.lr

+1-2
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,5 @@ name: Dhruv Bhanushali
55
md5_hashed_email: 0eab64adad056cff2492e7c407a9aa21
66
---
77
about:
8-
Dhruv Bhanushali is a Mumbai-based software developer and an Engineering-Physics graduate from IIT Roorkee. He started programming as a hobby in high-school and having found his calling, is now pursuing a career in the field. He is a huge fan of alternative and post-rock music and keeps his curated collection with him at all times. He also loves to binge watch TV shows and movies, especially indie art films.
98

10-
Dhruv developed [CC Vocabulary](https://opensource.creativecommons.org/cc-vocabulary/) as part of [Google Summer of Code 2019](/gsoc-2019/) and now is a maintainer for the project. He is consistently [`@dhruvkb`](https://dhruvkb.github.io/) everywhere.
9+
[Dhruv Bhanushali](https://dhruvkb.github.io/) is the Open Source Community Coordinator at Creative Commons. He goes by `@dhruvkb` on the CC Community Slack workspace. Dhruv developed [CC Vocabulary](https://opensource.creativecommons.org/cc-vocabulary/) as part of [Google Summer of Code 2019](/gsoc-2019/) and now is a maintainer for the project.

‎content/blog/entries/cc-search-accessibility-week3-4/contents.lr

+98
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
title: Internationalization Continued: Handling strings in the store
2+
---
3+
categories:
4+
cc-search
5+
community
6+
gsoc
7+
open-source
8+
9+
---
10+
author: AyanChoudhary
11+
---
12+
series: gsoc-2020-ccsearch-accessibility
13+
---
14+
pub_date: 2020-06-26
15+
---
16+
body:
17+
18+
These are the second two weeks of my internship with CC. I am working on improving the accessibility of cc-search and internationalizing it as well.
19+
The internationalization work from the previous post is continued here and we also solve an interesting issue of translating strings from the Vuex store.
20+
21+
During this period I removed all the hardcoded strings from the static pages which include:
22+
23+
1. About Page
24+
2. Collections Page
25+
3. Search Guide Page
26+
4. Feedback Page
27+
28+
All of the above pages were then internationalized following the same procedure as detailed in the previous post.
29+
While internationalizing the homepage we ran into an interesting problem:
30+
31+
The licenses strings were being accessed from the store and those too had to be internationalized.
32+
```
33+
licenseTypes: [
34+
{ code: 'commercial', name: 'Use commercially', checked: false },
35+
{ code: 'modification', name: 'Modify or adapt', checked: false },
36+
]
37+
```
38+
The code was used to store the licenses in the store in the ordered format. The challenge was to extract the name strings from each license while keeping the changes and dependencies to a minimum.
39+
The code which we were using in the templates to load these strings was:
40+
41+
```
42+
<label
43+
class="checkbox margin-right-big"
44+
:for="licenseType.code"
45+
:key="index"
46+
>
47+
<input
48+
:id="licenseType.code"
49+
type="checkbox"
50+
:checked="licenseType.checked"
51+
name="lt"
52+
:value="licenseType.code"
53+
@input="onFilterChanged(licenseType.code)"
54+
/>
55+
</ label>
56+
```
57+
58+
So after some discussion and a great insight by @brenoferreira we came up with the idea to change to name field from the store to point to our extracted internationalization strings.
59+
This proved to be very helpful as we managed to keep changes to a minimum without using any extra dependencies.
60+
The code after implementing the changes is:
61+
62+
```
63+
licenseTypes: [
64+
{ code: 'commercial', name: 'filters.license-types.commercial', checked: false, },
65+
{ code: 'modification', name: 'filters.license-types.modification', checked: false,},
66+
]
67+
```
68+
69+
```
70+
<label
71+
class="checkbox margin-right-big"
72+
:for="licenseType.code"
73+
:key="index"
74+
>
75+
<input
76+
:id="licenseType.code"
77+
type="checkbox"
78+
:checked="licenseType.checked"
79+
name="lt"
80+
:value="licenseType.code"
81+
@input="onFilterChanged(licenseType.code)"
82+
/>
83+
{{ $t(licenseType.name) }}
84+
</label>
85+
```
86+
87+
The rest of the internationalization stuff was string extractions and template modifications to accomodate the the translated strings.
88+
And we are done with these two weeks, we be back with another post after two weeks.
89+
90+
You can track the work done for these weeks through these PRs:
91+
92+
1. [Internationalize About Page and Search Guide Page](https://github.com/creativecommons/cccatalog-frontend/pull/1024)
93+
2. [Internationalize feedback page, collections page and not found page](https://github.com/creativecommons/cccatalog-frontend/pull/1031)
94+
95+
The progress of the project can be tracked on [cc-search](https://github.com/creativecommons/cccatalog-frontend)
96+
97+
CC Search Accessiblity is my GSoC 2020 project under the guidance of [Zack Krida](https://creativecommons.org/author/zackcreativecommons-org/) and [Ari Madian](https://opensource.creativecommons.org/blog/authors/akmadian/), who is the primary mentor for this project, [Anna Tumadóttir](https://creativecommons.org/author/annacreativecommons-org/) for helping all along and engineering director [Kriti
98+
Godey](https://creativecommons.org/author/kriticreativecommons-org/), have been very supportive.

‎content/blog/entries/cc-search-accessibility-week5-6/contents.lr

+80
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
title: Internationalization continued: Modifying tests
2+
---
3+
categories:
4+
cc-search
5+
community
6+
gsoc
7+
open-source
8+
9+
---
10+
author: AyanChoudhary
11+
---
12+
series: gsoc-2020-ccsearch-accessibility
13+
---
14+
pub_date: 2020-07-10
15+
---
16+
body:
17+
18+
These are the fifth and sixth weeks of my internship with CC. I am working on improving the accessibility of cc-search and internationalizing it as well.
19+
This post contains yet another important aspect to be taken care of while internationalizing the Vue components, i.e. modifying tests to include the changes.
20+
21+
The components which were left are the two pages displaying the most content:
22+
1. [Browse page](https://github.com/creativecommons/cccatalog-frontend/blob/develop/src/pages/BrowsePage.vue)
23+
2. [ImageDetail page](https://github.com/creativecommons/cccatalog-frontend/blob/develop/src/pages/PhotoDetailPage.vue)
24+
25+
The above two pages too were handled similar to the remaining pages, special care had to be taken in case of ImageDetail page since there are too many components in different files.
26+
By this point we also have our json structure figured out, mostly and are ready to push the json for fetching further translations.
27+
28+
Now let's look at the modifications required in the tests. We generally use ```$t``` to access strings from the locales json, but this method/custom-component is not present in the testing vue instance, so we had to inject this method usin localVue and a custom i18n instance.
29+
30+
```
31+
const localVue = createLocalVue();
32+
localVue.use(Vuex);
33+
localVue.use(VueI18n);
34+
const messages = require('@/locales/en.json');
35+
36+
const i18n = new VueI18n({
37+
locale: 'en',
38+
fallbackLocale: 'en',
39+
messages,
40+
});
41+
```
42+
43+
Now we inject this 18n component into our vue instance and we have access to our ```$t```, but there is still one more step left.
44+
We still need to mock its functionality in the tests. So we create a mock ```$t``` instance to mock in our component. The final code is given below:
45+
46+
```
47+
const $t = (key) => i18n.messages[key];
48+
49+
options = {
50+
mocks: {
51+
$t,
52+
},
53+
};
54+
```
55+
56+
Now we are ready to render our component using these custom options with mocks for testing.
57+
58+
And *drum rolls* we have successfully completed Internationalization of the complete cc search. Below are the images for some of the completed pages:
59+
60+
![final.png](final.png)
61+
62+
![finalAbout.png](finalAbout.png)
63+
64+
![finalImageDetail.png](finalImageDetail.png)
65+
66+
The issues closed with the completion of Internationalization are:
67+
68+
1. [[META] Internationalisation (i18n) Setup](https://github.com/creativecommons/cccatalog-frontend/issues/487)
69+
2. [Set up vue-i18n infrastructure](https://github.com/creativecommons/cccatalog-frontend/issues/941)
70+
3. [Create locale messages format JSON structure](https://github.com/creativecommons/cccatalog-frontend/issues/942)
71+
4. [Allow users to change locale on the client](https://github.com/creativecommons/cccatalog-frontend/issues/943)
72+
73+
You can track the work done for these weeks through this PR:
74+
75+
1. [Localize browsepage and single-result page](https://github.com/creativecommons/cccatalog-frontend/pull/1040)
76+
77+
The progress of the project can be tracked on [cc-search](https://github.com/creativecommons/cccatalog-frontend)
78+
79+
CC Search Accessiblity is my GSoC 2020 project under the guidance of [Zack Krida](https://creativecommons.org/author/zackcreativecommons-org/) and [Ari Madian](https://opensource.creativecommons.org/blog/authors/akmadian/), who is the primary mentor for this project, [Anna Tumadóttir](https://creativecommons.org/author/annacreativecommons-org/) for helping all along and engineering director [Kriti
80+
Godey](https://creativecommons.org/author/kriticreativecommons-org/), have been very supportive.

‎content/blog/entries/cc-search-accessibility-week5-6/final.png

78.7 KB
Loading

‎content/blog/entries/cc-search-accessibility-week5-6/finalAbout.png

128 KB
Loading

‎content/blog/entries/cc-search-accessibility-week5-6/finalImageDetail.png

1.21 MB
Loading

‎content/blog/entries/cc-search-accessibility-week7-8/contents.lr

+130
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
title: CC Search, Initial Accessibility Improvements
2+
---
3+
categories:
4+
cc-search
5+
community
6+
gsoc
7+
open-source
8+
9+
---
10+
author: AyanChoudhary
11+
---
12+
series: gsoc-2020-ccsearch-accessibility
13+
---
14+
pub_date: 2020-07-25
15+
---
16+
body:
17+
18+
These are the seventh and eighth weeks of my internship with CC. I am working on improving the accessibility of cc-search and internationalizing it as well.
19+
This post contains details of my work done to make initial accessibility improvements to homepage and the other static pages.
20+
21+
With the internationalization work complete, our next target were the accessiblity improvements. So I decided to tackle the homepage and the static pages first.
22+
The aforementioned pages had the following accessiblity issues:
23+
24+
1. No aria-label on links
25+
2. Improper landmarks
26+
3. Improper aria-control nestings
27+
4. Some elements not being read by the screen-reader
28+
5. Color contrast Issues(to be covered later)
29+
30+
But before working I ran another set of audit tests to exactly pin-point these issues. I used [NVDA](https://www.nvaccess.org/) for running these audits.
31+
Lets go through the fixes one at a time.
32+
33+
The first issue of no aria-label was pre-dominantly found in the footer. we had some links such as:
34+
```
35+
<a
36+
href="https://www.instagram.com/creativecommons"
37+
class="social has-text-white"
38+
target="_blank"
39+
rel="noopener"
40+
>
41+
```
42+
43+
These links did not contain any aria-label and were read as **cc link**. So the aria-labels had to be added ```aria-label="instagram link"``` in this case which fixed this problem.
44+
45+
The next issue was of improper landmarks. Most of the pages had no **main** landmark and some had no **complimentary** or **region** landmarks even though they were required in those pages.
46+
These landmarks had to be added after the carefully scrutinising the pages in the audits.
47+
48+
The next issue was of improper aria-control nestings. This is interesting as it involves having some deeper understanding of the roles involved. So I will explain this in a little depth.
49+
The area where we had this issue was in feedback page. The code involved was:
50+
51+
```
52+
<ul>
53+
<li :class="tabClass(0, 'tab')">
54+
<a
55+
href="#panel0"
56+
:aria-selected="activeTab == 0"
57+
@click.prevent="setActiveTab(0)"
58+
>
59+
Help us Improve
60+
</a>
61+
</li>
62+
<li :class="tabClass(1, 'tab')">
63+
<a
64+
href="#panel1"
65+
:aria-selected="activeTab == 1"
66+
@click.prevent="setActiveTab(1)"
67+
>
68+
Report a Bug
69+
</a>
70+
</li>
71+
</ul>
72+
```
73+
The reason why this is an error is because of the ```aria-selected``` attribute can only be applied to an element having the role **tab** nested inside a **tablist** element.
74+
For reference, in the above example the ```<ul>``` should have the role **tablist** and each ```<li>``` element should have the role **tab**. And so the ```aria-selected``` attribute should be in the ```<li>``` element instead of the ```<a>``` tag.
75+
76+
The corrected code is:
77+
```
78+
<ul role="tablist">
79+
<li role="tab" :class="tabClass(0, 'tab')" :aria-selected="activeTab == 0">
80+
<a
81+
aria-label="help us improve form"
82+
href="#panel0"
83+
@click.prevent="setActiveTab(0)"
84+
>
85+
{{ $t('feedback.improve') }}
86+
</a>
87+
</li>
88+
<li role="tab" :class="tabClass(1, 'tab')" :aria-selected="activeTab == 1">
89+
<a
90+
aria-label="report a bug form"
91+
href="#panel1"
92+
@click.prevent="setActiveTab(1)"
93+
>
94+
{{ $t('feedback.bug') }}
95+
</a>
96+
</li>
97+
</ul>
98+
```
99+
100+
Another interesting finding involved the screen readers not reading particular special characters such as ```~``` and ```|```.
101+
This issue was quite pronounced in the search guide page where these symbols were used in plenty in both links as well as texts.
102+
So I had to phonetically write these out in the aria-labels of the links to make the screen reader read them out loud.
103+
The corresponding changes are:
104+
105+
```
106+
<a
107+
aria-label="dog vertical bar cat"
108+
href="https://search.creativecommons.org/search?q=dog%7Ccat"
109+
>
110+
<em>dog|cat</em>
111+
</a>
112+
```
113+
114+
After all these changes we had some increase in the accessibility scores(computed from lighthouse):
115+
116+
1. About Page: 78 -> 97 | +19
117+
2. Search-Guide Page: 76 -> 97 | +23
118+
3. Feedback Page: 75 -> 97 | +22
119+
120+
Whoosh!! That was quite a lot. We are done with these two weeks for now. Hope to see you in the next post as well.
121+
122+
You can track the work done for these weeks through these PRs:
123+
124+
1. [Accessibility](https://github.com/creativecommons/cccatalog-frontend/pull/1068)
125+
2. [Accessibility Improvements](https://github.com/creativecommons/cccatalog-frontend/pull/1072)
126+
127+
The progress of the project can be tracked on [cc-search](https://github.com/creativecommons/cccatalog-frontend)
128+
129+
CC Search Accessiblity is my GSoC 2020 project under the guidance of [Zack Krida](https://creativecommons.org/author/zackcreativecommons-org/) and [Ari Madian](https://opensource.creativecommons.org/blog/authors/akmadian/), who is the primary mentor for this project, [Anna Tumadóttir](https://creativecommons.org/author/annacreativecommons-org/) for helping all along and engineering director [Kriti
130+
Godey](https://creativecommons.org/author/kriticreativecommons-org/), have been very supportive.

‎content/blog/entries/legal-database-features/404-page.png

42.1 KB
Loading

‎content/blog/entries/legal-database-features/contents.lr

+69
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
title: CC Legal Database: Developing features
2+
---
3+
categories:
4+
cc-legal-database
5+
product
6+
outreachy
7+
---
8+
author: krysal
9+
---
10+
series: outreachy-may-2020-legal-database
11+
---
12+
pub_date: 2020-08-07
13+
---
14+
body:
15+
In this post, I want to update the progress on Reimplementing the CC Legal Database site, my Outreachy project. There are several features added over the last month to date.
16+
17+
### Submission forms
18+
19+
The first thing I wanted to implement was the respective forms so that anyone can submit a case or article to the database. These forms were slightly modified in the redesign (discussed in the previous articles), so now it has fewer mandatory fields to lower the bar and facilitate the contribution of users.
20+
21+
<figure style="text-align: center;">
22+
<img src="scholarship-form.png" alt="Form to submit an article related to CC licenses" style="border: 1px solid black; width: 60%;">
23+
<figcaption>Scholarship form to submit an article.</figcaption>
24+
</figure>
25+
26+
For the Scholarship form, for example, it is only needed to share your name, email and a link to propose an article related to any of the CC licenses, although the more information you can provide us the better, in any case, each contribution is reviewed by the staff before publishing.
27+
28+
### Search
29+
30+
The second important task was to allow searching in each of the listings. A basic function to start making use of the exposed information. In the [current site](https://labs.creativecommons.org/caselaw/), this function is delegated to an external service, a certain famous search engine. Filtering is now performed in the backend based on the keywords entered by the user, thus returning the reduced list. Later this will be combined with filtering by tags or topics that are associated with each entry (case or scholarship).
31+
32+
### Automated tests
33+
34+
While developing the mentioned functionalities I was also in charge of adding automatic unit tests, to ensure that future changes to the code base do not damage already functional parts of the site. This, in addition to giving more confidence to future contributors, they provide value immediately, at the time of writing the tests you should think about possible edge cases, so they allowed me to notice a missing validation in a couple of routes and then correct it.
35+
36+
<figure style="text-align: center;">
37+
<img src="404-page.png" alt="404 page" style="border:1px solid black; width:70%;">
38+
<figcaption>Example of page obtained when requesting a case detail that is not published or doesn't exist.</figcaption>
39+
</figure>
40+
41+
In this process of adding automated tests I wanted them to run on every pull request created, so I learned how to write a GitHub Action with a PostgreSQL service, the DBMS used in this case. Previously, I had already created a job for linting, so I needed to add another one to run in parallel to save time. This service provided by GitHub is pretty cool and useful, it opens up a world of possibilities, from running third party services like [Lighthouse test](https://github.com/GoogleChrome/lighthouse-ci) to even [send tweets](https://github.com/gr2m/twitter-together)! If you want to see the GitHub Action file configurated for this project, check it out: [`.github/workflows/main.yml`](https://github.com/creativecommons/caselaw/blob/31c3002a7860d78f3fdb464150c5c1b2f8bb86fc/.github/workflows/main.yml).
42+
43+
### Accessibility
44+
45+
To check if the site had shortcomings I did the Lighthouse test on the homepage, discovering that there were indeed some issues to tackle. In principle the results were these:
46+
47+
<figure style="text-align: center;">
48+
<img src="lighthouse-before.png" alt="" style="border:1px solid black; width:70%;">
49+
<figcaption>Initial Lighthouse test measurements.</figcaption>
50+
</figure>
51+
52+
The good thing about this test is that it throws up suggestions on how to fix the bugs found, so after adding certain missing attributes and labels, the following results were achieved.
53+
54+
<figure style="text-align: center;">
55+
<img src="lighthouse-after.png" alt="" style="border:1px solid black; width:70%;">
56+
<figcaption>Lighthouse test measurements after corrections.</figcaption>
57+
</figure>
58+
59+
There is still room for improvement but at least we are within a quite acceptable green range.
60+
61+
### Other features and tweaks
62+
63+
Some other features were implemented but only relevant to our registered users, that is, the Legal Staff. They consist of Django admin customization, such as filtering records by status, and a particular thing requested, the answers of frequently asked questions need to be displayed formatted, so they are now saved as Markdown text and transformed to HTML with style on the public site, showing lists, bold text, links, etc. The admin can also see a preview while editing.
64+
65+
### Conclusion
66+
67+
After reviewing all done this last month I see significant progress has been made, I have learned many things along the way: more of what Django and its ecosystem offers, about accessibility, continuous integration in Heroku and GitHub, and more. One of the things that makes me most happy is being able to be contributing and being part of an Open Source organization, knowing how it moves and works inside, something I never imagine before.
68+
69+
Time flies and there are less than two weeks left to finish, so if you want to follow the project here is the repository to suggest improvements or report bugs, or if you prefer something less technical you can join us on the [slack channel](https://creativecommons.slack.com/channels/cc-dev-legal-database).

‎content/blog/entries/legal-database-features/lighthouse-after.png

38.8 KB
Loading

‎content/blog/entries/legal-database-features/lighthouse-before.png

40.9 KB
Loading

‎content/blog/entries/legal-database-features/scholarship-form.png

67.7 KB
Loading

0 commit comments

Comments
 (0)