Hello everyone, I'll introduce myself for those of you who didn't "git blame" me... I'm the one who introduced that huge, nasty, blocking bug, that didn't ley you place a simple hold on intranet. I'm glad to announce that patch is on the way, and passed QA. This was one of the first steps (if not the first) of using the API in intranet. A really clumpsy step, I give you that, but as they saying says.. "That's one small step for [a] man, one giant leap for the API", but in my case, if I've been Neil Armstrong, I've probably tripped as soon as I got out of the module, get my helmet all scratched and filled with moon dust, and instead of a nice clean footprint, there would have been a fuzzy figure resembling a space suit trying to get up. Marcel de Rooy, the generous soul who passedQA the solution patch, complained (and he was absolutely right) about a couple of things: 1. That there was no comunication about this in dev channel before implementing. It's too late for discusing before implementing, but I would really like to know your opinion post implementation. 2. OPAC and Intranet now use diferent methods to place holds.. one uses the API, the other uses a POST to a .pl file. I think it best to move OPAC to use the API, but this time I'm going to hear you first. Regards
I think it best to move OPAC to use the API, but this time I'm going to hear you first.
Would this make the holds process dependent on JavaScript? Owen -- Web Developer Athens County Public Libraries https://www.myacpl.org
I'm going to go out on a limb and say it will indeed require javascript. There are a number of OPAC features ( though non-essential ) that don't function without javascript. Is this still a requirement for the OPAC? Kyle --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Oct 4, 2019 at 12:30 PM Owen Leonard <oleonard@myacpl.org> wrote:
I think it best to move OPAC to use the API, but this time I'm going to hear you first.
Would this make the holds process dependent on JavaScript?
Owen
-- Web Developer Athens County Public Libraries https://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Yeah I guess we reached the point that we just need javascript in OPAC ? Museumstraat 1 Postbus 74888 1070 DN Amsterdam Rijksmuseum.nl Nu te zien: Louise Bourgeois in de Rijksmuseumtuinen Operatie Nachtwacht Verwacht: Rembrandt-Velázquez. Nederlandse & Spaanse meesters T/m 18 jaar gratis Please think before you print
I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
Yeah I guess we reached the point that we just need javascript in OPAC ?
[image: http://www.rijksmuseum.nl] <http://www.rijksmuseum.nl/>
Museumstraat 1 Postbus 74888 1070 DN Amsterdam *Rijksmuseum.nl* <http://www.rijksmuseum.nl/> Nu te zien: *Louise Bourgeois in de Rijksmuseumtuinen* <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> *Operatie Nachtwacht* <https://www.rijksmuseum.nl/nl/nachtwacht> Verwacht: *Rembrandt-Velázquez. Nederlandse & Spaanse meesters* <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> T/m 18 jaar gratis
Please think before you print _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries. Katrin On 07.10.19 13:28, Kyle Hall wrote:
I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <M.de.Rooy@rijksmuseum.nl <mailto:M.de.Rooy@rijksmuseum.nl>> wrote:
Yeah I guess we reached the point that we just need javascript in OPAC ?
http://www.rijksmuseum.nl <http://www.rijksmuseum.nl/>
Museumstraat 1 Postbus 74888 1070 DN Amsterdam *Rijksmuseum.nl* <http://www.rijksmuseum.nl/> Nu te zien: *Louise Bourgeois in de Rijksmuseumtuinen* <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> *Operatie Nachtwacht* <https://www.rijksmuseum.nl/nl/nachtwacht> Verwacht: *Rembrandt-Velázquez. Nederlandse & Spaanse meesters* <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> T/m 18 jaar gratis
Please think before you print
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I agree with Katrin. I think we need to be careful to think as developers in the open source GLAM space rather than the less accountable corporate space. While I’m a few years out of date when it comes to accessibility, I do still have some friends who are experts in that area and could get their opinion on the matter. From what I remember, Javascript != accessible. I think it was because screenreaders, at least historically, didn’t render the Javascript and that caused the lack of functionality for people with accessibility needs. I’d also add that we can use the API without using Javascript. We could build a lightweight controller which does the API call on the server backend rather than from the client browser, so the user could POST to a CGI .pl script (or a PSGI route), and the API handles all the real business logic. If we wanted to be modern, we could use Javascript to call the API, but fail gracefully by POSTing the form instead if Javascript turns off. I know that would be a lot more work, but that could way we could keep the modernity while also maintaining accessibility. Just my 2 cents. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Katrin Fischer Sent: Tuesday, 8 October 2019 7:31 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] API use in intranet and OPAC If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries. Katrin On 07.10.19 13:28, Kyle Hall wrote: I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <M.de.Rooy@rijksmuseum.nl <mailto:M.de.Rooy@rijksmuseum.nl> > wrote: Yeah I guess we reached the point that we just need javascript in OPAC ? <http://www.rijksmuseum.nl/> Museumstraat 1 Postbus 74888 1070 DN Amsterdam <http://www.rijksmuseum.nl/> Rijksmuseum.nl Nu te zien: <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> Louise Bourgeois in de Rijksmuseumtuinen <https://www.rijksmuseum.nl/nl/nachtwacht> Operatie Nachtwacht Verwacht: <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> Rembrandt-Velázquez. Nederlandse & Spaanse meesters T/m 18 jaar gratis Please think before you print _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
One but not least issue with JavaScript, how do we test this? I mean it's easy to test the API itself, making requests to it and monitoring the change in the koha db or mock objects. It's also easy to check if the Intranet or Opac page returned by the server contains some strings in the html code (I guess, didn't try though). How do we execute the Javascript in the test and verify it has the expected behavior? Overall I have to say I'm very happy with this change (using more API) though, since it will raise interest for this further and can bring Koha to a whole new level within libraries app, Koha being at the core of other third parties apps to interact with (not to mention them: Coral ERMS and Bokeh Library Frontend). \o/ Le 8 octobre 2019 01:53:59 GMT+02:00, dcook@prosentient.com.au a écrit :
I agree with Katrin. I think we need to be careful to think as developers in the open source GLAM space rather than the less accountable corporate space. While I’m a few years out of date when it comes to accessibility, I do still have some friends who are experts in that area and could get their opinion on the matter. From what I remember, Javascript != accessible. I think it was because screenreaders, at least historically, didn’t render the Javascript and that caused the lack of functionality for people with accessibility needs.
I’d also add that we can use the API without using Javascript. We could build a lightweight controller which does the API call on the server backend rather than from the client browser, so the user could POST to a CGI .pl script (or a PSGI route), and the API handles all the real business logic.
If we wanted to be modern, we could use Javascript to call the API, but fail gracefully by POSTing the form instead if Javascript turns off. I know that would be a lot more work, but that could way we could keep the modernity while also maintaining accessibility.
Just my 2 cents.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Katrin Fischer Sent: Tuesday, 8 October 2019 7:31 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] API use in intranet and OPAC
If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries.
Katrin
On 07.10.19 13:28, Kyle Hall wrote:
I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript.
---
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <M.de.Rooy@rijksmuseum.nl <mailto:M.de.Rooy@rijksmuseum.nl> > wrote:
Yeah I guess we reached the point that we just need javascript in OPAC ?
Museumstraat 1 Postbus 74888 1070 DN Amsterdam <http://www.rijksmuseum.nl/> Rijksmuseum.nl Nu te zien: <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> Louise Bourgeois in de Rijksmuseumtuinen <https://www.rijksmuseum.nl/nl/nachtwacht> Operatie Nachtwacht Verwacht: <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> Rembrandt-Velázquez. Nederlandse & Spaanse meesters T/m 18 jaar gratis
Please think before you print
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53
Testing is always an interesting one. I’d say unit tests for the API functions and unit tests for the controller functions. You could mock the API for the latter. For integration tests, you could use selenium to test the integration between the two. Alternatively, manual integration tests. Personally, I’m hugely in favour of using the API for all business logic for OPAC functionality. The Koha OPAC could be a reference implementation and out-of-the-box solution, but then third party apps and library websites could opt out of using the Koha OPAC and instead just integrate with the API directly. I think a lot of my clients would actually prefer to integrate a Koha OPAC API into their own websites rather than using the Koha OPAC website. I suppose one downside could be the Koha OPAC website could become neglected, if everyone was just maintaining their own user interfaces. But I imagine a lot of people would still want to use the Koha OPAC website too. (After all, integrating with third-party APIs can be very challenging too!) David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Arthur Suzuki <arthur.suzuki@biblibre.com> Sent: Tuesday, 8 October 2019 11:17 AM To: koha-devel@lists.koha-community.org; dcook@prosentient.com.au; 'Katrin Fischer' <katrin.fischer.83@web.de> Subject: Re: [Koha-devel] API use in intranet and OPAC One but not least issue with JavaScript, how do we test this? I mean it's easy to test the API itself, making requests to it and monitoring the change in the koha db or mock objects. It's also easy to check if the Intranet or Opac page returned by the server contains some strings in the html code (I guess, didn't try though). How do we execute the Javascript in the test and verify it has the expected behavior? Overall I have to say I'm very happy with this change (using more API) though, since it will raise interest for this further and can bring Koha to a whole new level within libraries app, Koha being at the core of other third parties apps to interact with (not to mention them: Coral ERMS and Bokeh Library Frontend). \o/ Le 8 octobre 2019 01:53:59 GMT+02:00, dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> a écrit : I agree with Katrin. I think we need to be careful to think as developers in the open source GLAM space rather than the less accountable corporate space. While I’m a few years out of date when it comes to accessibility, I do still have some friends who are experts in that area and could get their opinion on the matter. From what I remember, Javascript != accessible. I think it was because screenreaders, at least historically, didn’t render the Javascript and that caused the lack of functionality for people with accessibility needs. I’d also add that we can use the API without using Javascript. We could build a lightweight controller which does the API call on the server backend rather than from the client browser, so the user could POST to a CGI .pl script (or a PSGI route), and the API handles all the real business logic. If we wanted to be modern, we could use Javascript to call the API, but fail gracefully by POSTing the form instead if Javascript turns off. I know that would be a lot more work, but that could way we could keep the modernity while also maintaining accessibility. Just my 2 cents. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Koha-devel <koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> > On Behalf Of Katrin Fischer Sent: Tuesday, 8 October 2019 7:31 AM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] API use in intranet and OPAC If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries. Katrin On 07.10.19 13:28, Kyle Hall wrote: I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <M.de.Rooy@rijksmuseum.nl <mailto:M.de.Rooy@rijksmuseum.nl> > wrote: Yeah I guess we reached the point that we just need javascript in OPAC ? <http://www.rijksmuseum.nl/> Museumstraat 1 Postbus 74888 1070 DN Amsterdam <http://www.rijksmuseum.nl/> Rijksmuseum.nl Nu te zien: <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> Louise Bourgeois in de Rijksmuseumtuinen <https://www.rijksmuseum.nl/nl/nachtwacht> Operatie Nachtwacht Verwacht: <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> Rembrandt-Velázquez. Nederlandse & Spaanse meesters T/m 18 jaar gratis Please think before you print _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53
Hi, On Tue, 8 Oct 2019 at 06:17, <dcook@prosentient.com.au> wrote:
I suppose one downside could be the Koha OPAC website could become neglected, if everyone was just maintaining their own user interfaces. But I imagine a lot of people would still want to use the Koha OPAC website too. (After all, integrating with third-party APIs can be very challenging too!)
I agree. For library professionals without programming skills or access to qualified IT support, who are bootstrapping their library automation using Koha, the OPAC is central key feature. I see the OPAC continuing to remain important to that user segment for at least the next 5 years. Cheers Indranil Das Gupta L2C2 Technologies
Hi, Just wondering if there is any way to define the Mana Url in some environment variable when setting up the koha-testing-docker. Wish to do some testing on those solutions and wonders if I could do it on a local and easily reproductible environment. Looked around, couldn't find. Thanks in advance for your help :) Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53
File an issue on gitlab with the proposed behavior! El mar., 8 de octubre de 2019 18:35, Arthur Suzuki < arthur.suzuki@biblibre.com> escribió:
Hi, Just wondering if there is any way to define the Mana Url in some environment variable when setting up the koha-testing-docker. Wish to do some testing on those solutions and wonders if I could do it on a local and easily reproductible environment. Looked around, couldn't find. Thanks in advance for your help :) Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Ok i'd rather try to submit a merge request then ;) Le 9 octobre 2019 04:00:13 GMT+02:00, Tomas Cohen Arazi <tomascohen@gmail.com> a écrit :
File an issue on gitlab with the proposed behavior!
El mar., 8 de octubre de 2019 18:35, Arthur Suzuki < arthur.suzuki@biblibre.com> escribió:
Hi, Just wondering if there is any way to define the Mana Url in some environment variable when setting up the koha-testing-docker. Wish to do some testing on those solutions and wonders if I could do it on a local and easily reproductible environment. Looked around, couldn't find. Thanks in advance for your help :) Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53
+1 for me. I'm sure modern web-browsers can provide a good accessiblity even with JS/Ajax. Le 07/10/2019 à 13:28, Kyle Hall a écrit :
I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <M.de.Rooy@rijksmuseum.nl <mailto:M.de.Rooy@rijksmuseum.nl>> wrote:
Yeah I guess we reached the point that we just need javascript in OPAC ?
http://www.rijksmuseum.nl <http://www.rijksmuseum.nl/>
Museumstraat 1 Postbus 74888 1070 DN Amsterdam *Rijksmuseum.nl* <http://www.rijksmuseum.nl/> Nu te zien: *Louise Bourgeois in de Rijksmuseumtuinen* <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> *Operatie Nachtwacht* <https://www.rijksmuseum.nl/nl/nachtwacht> Verwacht: *Rembrandt-Velázquez. Nederlandse & Spaanse meesters* <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> T/m 18 jaar gratis
Please think before you print
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Fridolin SOMERS <fridolin.somers@biblibre.com> BibLibre, France - software and system maintainer
This certainly makes me wonder. In Australia, JAWS appears to be the recommended Microsoft Windows screen reader (https://www.visionaustralia.org/information/adaptive-technology/using-techno...), and the Wikipedia entry says that Internet Explorer is the recommended browser for JAWS (https://en.wikipedia.org/wiki/JAWS_(screen_reader)). After some searching around, it seems that there are a mix of Accessibility APIs out there. The free screen reader NVDA (https://www.nvaccess.org/download/) is said to work best with Firefox (and it looks like Firefox and Chrome may use the same API protocols so maybe it works well in Chrome too). I haven't noticed anything about specific browser versions at this point. I know we use ARIA attributes a bit... mostly through Bootstrap boilerplate I think: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA After reading https://www.levelaccess.com/how-browsers-interact-with-screen-readers-and-wh..., I think it would be naïve to think that we can make Koha totally accessible without more specialized knowledge and resources. Plus, most modern web apps out there that people are interacting with are using Javascript. (Although they might be implemented in a way that is conducive to screen reader use.) I think a number of Koha developers use Mac, which I think comes with VoiceOver. They could see how well that fares with Koha. I had a classmate from Atlassian build a completely Javascript driven app and he leveraged VoiceOver to read the screen (it was a flashcard app for learning Chinese). So perhaps modern technology is sufficiently advanced at this point not to have to worry too much. I'm not saying that we should mandate accessibility at this point as that could be a prohibitive mandate for contributions, but it might be interesting to try out some tools to see how we're doing and if there is little things we could do to try to do the best we can for people with accessibility needs. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Fridolin SOMERS Sent: Monday, 14 October 2019 6:24 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] API use in intranet and OPAC +1 for me. I'm sure modern web-browsers can provide a good accessiblity even with JS/Ajax. Le 07/10/2019 à 13:28, Kyle Hall a écrit :
I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <M.de.Rooy@rijksmuseum.nl <mailto:M.de.Rooy@rijksmuseum.nl>> wrote:
Yeah I guess we reached the point that we just need javascript in OPAC ?
http://www.rijksmuseum.nl <http://www.rijksmuseum.nl/>
Museumstraat 1 Postbus 74888 1070 DN Amsterdam *Rijksmuseum.nl* <http://www.rijksmuseum.nl/> Nu te zien: *Louise Bourgeois in de Rijksmuseumtuinen* <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> *Operatie Nachtwacht* <https://www.rijksmuseum.nl/nl/nachtwacht> Verwacht: *Rembrandt-Velázquez. Nederlandse & Spaanse meesters* <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> T/m 18 jaar gratis
Please think before you print
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Fridolin SOMERS <fridolin.somers@biblibre.com> BibLibre, France - software and system maintainer _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
We found a few other intranet places as well (thx Katrin). The first comes from bug 8030, august 2016. root@master:/usr/share/koha/koha-tmpl/intranet-tmpl/prog# git grep -l "/api/v1/" [Bug 15496 12-04-19] en/modules/cataloguing/moveitem.tt [Bug 23710 01-10-19] en/modules/reserve/request.tt [FIRST REPORT Bug 8030 19-08-16] js/holds.js [Bug 18589, but originated from bug 7317 03-02-17] js/ill-list-table.js [Bug 11897 01-10-2018] js/pages/stockrotation.js root@master:/usr/share/koha/koha-tmpl/opac-tmpl/bootstrap# git grep -l "/api/v1/" [FIRST OPAC Bug 23623 16-09-2019] en/modules/opac-memberentry.tt ________________________________ Museumstraat 1 Postbus 74888 1070 DN Amsterdam Rijksmuseum.nl Nu te zien: Louise Bourgeois in de Rijksmuseumtuinen Operatie Nachtwacht Verwacht: Rembrandt-Velázquez. Nederlandse & Spaanse meesters T/m 18 jaar gratis Please think before you print Van: Koha-devel <koha-devel-bounces@lists.koha-community.org> namens Agustin Moyano <agustinmoyano@theke.io> Verzonden: vrijdag 4 oktober 2019 18:22 Aan: Koha-devel@lists.koha-community.org <Koha-devel@lists.koha-community.org> Onderwerp: [Koha-devel] API use in intranet and OPAC Hello everyone, I'll introduce myself for those of you who didn't "git blame" me... I'm the one who introduced that huge, nasty, blocking bug, that didn't ley you place a simple hold on intranet. I'm glad to announce that patch is on the way, and passed QA. This was one of the first steps (if not the first) of using the API in intranet. A really clumpsy step, I give you that, but as they saying says.. "That's one small step for [a] man, one giant leap for the API", but in my case, if I've been Neil Armstrong, I've probably tripped as soon as I got out of the module, get my helmet all scratched and filled with moon dust, and instead of a nice clean footprint, there would have been a fuzzy figure resembling a space suit trying to get up. Marcel de Rooy, the generous soul who passedQA the solution patch, complained (and he was absolutely right) about a couple of things: 1. That there was no comunication about this in dev channel before implementing. It's too late for discusing before implementing, but I would really like to know your opinion post implementation. 2. OPAC and Intranet now use diferent methods to place holds.. one uses the API, the other uses a POST to a .pl file. I think it best to move OPAC to use the API, but this time I'm going to hear you first. Regards
participants (10)
-
Agustin Moyano -
Arthur Suzuki -
dcook＠prosentient.com.au -
Fridolin SOMERS -
Indranil Das Gupta -
Katrin Fischer -
Kyle Hall -
Marcel de Rooy -
Owen Leonard -
Tomas Cohen Arazi